Hi, I'm Kevin, Michelle, and Kylian, and we're here at the Colorado Moderero Museum, and December's What's Neat starts right now. The What's Neat show is sponsored by Caboose, sharing our passion for trains since 1938. This is What's Neat for December 2018. I'm your host Ken Patterson, and this month we've got a really good show. First of all, Joe Hudson shows us how to paint figures, but not before he makes a lot of paper clips first. It's pretty amazing to know what it is his art. Brad Joseph, we look at his gorgeous Union Pacific layout. I shot this layout a long time ago back in 1995 for the Annamarie Bulletin, and boy has this layout changed. Jeff Meyer stops by and shares with us a really cool boxcar that he weathered up for us, and of course George Bugatuck. I interviewed a really great segment with him, where he actually prepared all the video for us doing a install into a Broadway limited M1 locomotive that I had had. And in fact, it just came out fantastic. So most of this show, about 45 minutes of this hour long show, we are going to spend in Colorado. Of course, George is in Durango, but we also share the Colorado Model Railroad Museum on this show. It's an absolutely fantastic layout in the beautiful town of Greeley, Colorado, a nice town with all the quaint little shopping districts, and of course the Union Pacific mainline runs right through the center of town. This is an absolutely magnificent museum built by David Trussell, the founder of the Colorado Model Railroad Museum in Greeley, Colorado. He definitely has a passion for trains. A model railroader since his childhood, he has built many home layouts. Building on his experiences, he formed the Greeley and Tahoe modular layout. Now, I remember this layout well. When I brought the Midwest Valley modelers' layout to Kansas City to that Annamarie show, I remember Dave's modular layout was just set up two layouts away, with realistic scenery, brown skirting, model ships, and a port that I will never forget. Dave started working on his life's masterpiece, the Greeley Freight Station Museum layout, by planning a very detailed track design. The museum's name was later changed to the Colorado Model Railroad Museum. This layout's principal railroad is called the Oregon, California, and Eastern Railroad, which took over 10 years to plan and construct and complete with its own 10,000 square foot building to house it. The building is filled with a life's collection of over 1,100 railroad artifacts and collectible memorabilia, including the 5,500 square foot double deck layout, measuring about 60 feet by 98 feet. Additionally, there is a prototype Colorado and Southern caboose number 10583, fully restored to its original condition. This caboose will turn 100 years old in July 2019 with a birthday party sure to draw a crowd. The layout itself is an engineering marvel with over 21 scale miles of track and a mainline run of over 1,300 feet. It's a double deck point-to-point design for operation with a fully functional CTC panel via dispatcher dictating all the train movements on the entire layout. The layout has an array of scale trestles and bridges, which are all hand-built with thousands of pieces of individual scale lumber. Minimum radiuses on the mainline of 48 inches brings the train through the 2.5% grades very smoothly between the levels and a viewing track height of about 40 to 98 inches from the floor. The tracks run between towns with the lumber industry being one of the main industries represented on this layout. From the forest to the lumber mills to the shipping and transportation ports, the lumber industry from tree to finished product is modeled in its total entirety on this layout. During a normal operating session, operators run 14 freight trains with 8 or so locals in both directions on the single track mainline with passing sightings that can easily hold the 80 car freight trains as they pass each other on their way to their destinations. An elevated viewing platform runs for the entire length of the building, giving a bird's eye view of the layout, which is quite interesting. There is a 95 foot long staging yard under the full-length viewing platform, and I gotta tell you this area is a beehive of activities as the operators depart and arrive with their long freight trains. The shipping port is complete with petroleum transfer facilities along with lumber and general freight. The ships are simply magnificent. Radio controlled, they are fully functional with full lighting and propulsion when floating in real water. They are on display on rolling platforms right next to the docks, which can be rolled into place and rolled out of place as they're loaded and emptied. The full scale model of the Edmund Fitzgerald, it's a total work of art. Complete with a full crew, really detailed cranes, superstructure, even the clamps on the deck lids are there. It is totally tricked out with detail. It's an equally impressive ore dock as you see runs the full length of this ore freighter. This is just an absolutely beautiful model to witness. I spent two days at the layout and I never really got a chance to see all of it, or even have a time to grab a throttle and try my hand at operation. But what I did get was a great interview with the executive director of the museum, Michelle Kempema, in the final hours of my visit right before catching a plane back to St. Louis. And I gotta say, thank you very much Ed Dressel and Kilian Rubel for some fantastic camera work. It really turned out to be a great interview. So with that, let me present to you the Colorado Model Railroad Museum. For this segment of What's Neat, I'm standing with Michelle Kempema, the executive director of the Colorado Model Railroad Museum here in Greeley, Colorado, and what a magnificent layout that we are standing in here in all of its ambience. Michelle, this has got to be absolutely incredible to have a job where you work in a place like this. I do love my job. I have the best job on the planet and the best hobby in the world, right? I do love what I do. I definitely have a passion for what we do here. You put in a lot of hours and you have a lot of interaction with a lot of great individuals.  Well, I love the people that come through the door and I love our volunteers and I try to know everyone that comes in here because it's an experience and we want you to come in here and be immersed in this world. Yes. And so part of that is interacting with people because part of your experience here is not only seeing the trains but hearing them and the people around you and seeing the engineers with their trains and just the whole experience all goes together. That's absolutely fantastic. And you put a lot of hours. You not just work the trains but you work this entire business and you do very well. You guys have got some fantastic programs that I've learned about in the last two days of spending time here at this museum which while I will say as a fomer, dude, this is awesome. I love it. You all have got to check this place out. I am so overwhelmed. This is awesome that the fact is you run a very professional outfit here that actually helps the community and supports the hobby of model trains. Tell us about that pleasant seat. Well, what we have is a model railroad experience that sets in our community and our state and we try to be a part of our community in our local area and internationally. We want to be a part of the world of model railroading and we want to bring people joy with model trains. It's in our mission bringing people joy. And what better way to bring people joy than to come in here and look around and just fall in love with model railroading in here. Now, Michelle is on the podcast with us when you watch the What's Neat This Week podcast and one thing that we're going to talk about that I found fascinating is that on this 5,500 square foot layout, the maintenance, which I asked her about in podcast 51, we touched on lightly. But I saw us here. You all have a three page aircraft flight checklist on a procedure to maintain this layout. And that's something that in future podcasts I'd like to talk about. But this layout is so large. This is not like a home layout. It's not just humidity that they worry about, which they've got that controlled. It's the constant air systems control of the environment. The lumber underneath this layout is literally that of a home construction. You've got to build levels of platforms for the public to walk in, sustain the weight, and then sustain the layout. I've shot all of this and it's absolutely amazing. And tell us about the gorgeous scenery on this layout, Michelle. This is some of the finest scenery you will ever see. And it is all handmade. 28,000 handmade trees around us right now. And they're of all kinds. And I made an aspen and it took a long time. So when you're in here, you will see that our rocks were made from molds we made. Everything was hand painted and done. And so it really is just excellence in scenery. When I look at the layout, I really enjoy all the different types of bridges. Yeah, we have 14 bridges on this layout of many different kinds. They're all hand built and they're just beautiful. I love the bridges because the photograph you get, even visitors, can get that quality photograph, like a Ken Patterson photograph in our layout. I love it. Now you've got this gorgeous caboose that you refer to as she. Tell us your passion about that.  That's all you could say. She was built in 1919, Colorado and Southern. Her first job is running beer from Coors to Denver. I mean that's got to be fun, right? And then she ended up on the Colorado and Southern line that runs right alongside her building. And so in her history, she actually worked right where we are right now. And so we were able to restore her and share her with the world. And she turns 100 next year. That's fantastic. Now, when I was here earlier, they were doing a nighttime operating mode that I didn't really shoot a lot of b-roll up. But the fact is you have complete control of the lights. Tell us about that. We do. We have a theater lighting in here. So we can do day, night, and then we've lit much of the layout except when you're out in the country, it's a little dark. But that's the fun, right? Right. And so we do night-ups for our volunteers that come in and do it. It's fun. How many volunteers would you guys to meet you have? We have about 100 active volunteers at any time. And I've met so many of them, some of the best people in the world. And you've got, I've met a couple of people on the board that run this incredible operation. You've got some really good people behind you. We do. We have, I think, the most excellent people here. And I think part of that is just our philosophy of we're all here to provide this experience. So we're not like a club. We're totally different. We're made up of people from so many clubs from all across the country. Well, we had New Mexico in here today. I have a group from Iowa that comes all the time. We're really a national volunteer base. Right. And this is just the beginning of what's going to be a larger presentation of trains. Would you like to elaborate what some of your dreams might be for this? Oh, dreams would take a long time. Okay, we'll pick a couple. Well, our youth programs, we were teaching in public schools, we're building layouts with kids at Boys and Girls Club. We have after-school programs, summer camps. We're doing all kinds of that, so we need space. I need a massive creative room that we can make messes in and build amazing layouts. We also have exhibits we want to tell the story of model railroading through history in really interesting and creative ways. And so there's going to be a lot in what we build in our expansion. It's really exciting. In my couple of days here, one of the most famous model railroaders that we're going to have on the show in the third week of November is Rand Hood. And Rand Hood's going to help you with this project. Is that right? He is. He's coming to help me do some dreaming. It's awesome. I'm excited. This is going to be so great. This is going to be the center point in Colorado of model railroading. In between you and our sponsor, Caboose, there's a lot of great things to come. So look forward to that. Also, I want to thank Michelle so much for being the new podcast member of our crew. We're going to share a lot of experiences here from the museum with all of our viewers on that podcast. But for this segment of What's Neat, I don't know how we can make it any better than what it is. This is one of the best, most massive layouts that I've seen well organized and it's got great leadership, right? Well, I hope so. I do my best. Thank you so much for being part of this segment of What's Neat. Thank you. Thanks for having me. Thanks for coming out. And so you can come to Colorado. You can go to Caboose and you can come see us all in one day. It's awesome. This is the best hobby in the world. For this segment of What's Neat, I'm with Brad Joseph here in O'Fallon, Illinois, and I'm standing in this gorgeous double deck Union Pacific layout, Brad. Right on. This is awesome, buddy. Now I shot your layout way back in 1995 for the NMRA Bulletin and boy, has it changed. Yes, it's changed a little bit. I've redone a lot of the scenery. I had more hair then, a little bit less stress, but I've been working on it a long time. Too long, some may say. You know, looking at all of this, you have a passion for trains. Where does this come from with you, Brad? Oh man, that's easy. It came from my dad, Ken. Literally, my first memory was sitting on my dad's lap while he was working on a brass steam engine. I know what the steam engine was. It was a PFM Sierra 2662, which was his favorite engine of all time. And every vacation trip was riding fan trips, photograph and locomotive, steam trains, official guide was always in the car. That's where it came from. No doubt Osmosis, I think they call that if I'm not mistaken. I've got a picture of you in one of my real grand books in my library, writing to Zephyr. Tell me about that moment. Oh wow, that was our honeymoon. That's David Goodhart's book, right? Zephyr through the Rockies. David Goodhart and Harold Edmondsson. I wrote the real grand Zephyr seven times. First time was 1972 with my mom and dad. And I actually did a video slideshow on that that's on YouTube and I got to present at Beecher Fest a few years ago. The real grand Zephyr was a real passion of mine. I really enjoyed it. In fact, my wife and I just recently rode the Silver Solarium and Silver Rapids, the California Zephyr cars, they're still running. Everybody loves the California Zephyr, right? Now looking at your layout, you've got so much colorful scenery. You've got this gorgeous winter section where it's really kind of like this reddish scenery of, you know, the Rocky Mountains. Is that what they tell me about the winter scene? Well, the winter scene is little unusual. As you know, not many people do winter. I love winter scenes. I love to play hockey. I'm a skier and I really enjoy that kind of scenery. But that is representative Echo and Weber canyons coming east out of Ogden, Utah, which is where the big boy was built to climb up the Wasatch grade. Those are the Wasatch Mountains. And an interesting thing about that part of the country, depending on the time of the day, the light or the rocks are redder. Sometimes they're grayer. But all those scenes are modeled after actual locations, a place called Devil Slide, double bridges coming out of a tunnel called Taggart's. So that's what that all is. I kind of skip. I cut about 300 miles from West Allermy to Wasatch, Utah. We just kind of zip right past there and head right into those canyons. As we go down your single track main lines, you go from town to town through the beautiful, colorful scenery. It does look like Union Pacific Territory. And then we end up at this gorgeous roundhouse that you've built. Tell me about that scene. Wow. That actually was the toughest thing I've ever built in my life, because the whole thing is scratch built. And it's all exact scale measurements of the Union Pacific Roundhouse in Cheyenne, Wyoming. And steam locomotives are my number one passion. So I've got a lot of them. Most of them reside too much time in the roundhouse. But no, I love roundhouses. I seek them out to photograph them now. There aren't a whole lot left. And so I built that a long time ago. I think it looks pretty good if I'm not mistaken. One aspect of the hobby that you pointed out to me tonight is that you really enjoy operation. Talk to me a little bit about that. And is it the fellowship that it brings that you like too? Well, a combination of everything. The operating part, it's the culmination of this thing, right? We build this, then what do we do? We sit back and look at it and think, well, what do we do next? So the operating thing, my dad and I used to operate our layouts back in the early 70s. In fact, I still got a rulebook from that my mom typed it up that my dad wrote up the rulebook in the early 70s. But regardless, the trains that I run are representations of the real trains, the passion train numbers, the consists are right. I really enjoy that sort of thing. And the fellowship, of course, is great. Ribbon everybody over running a switch, which apparently my operators are the only guys that ever run a switch. I've never seen that happen elsewhere. But yeah, it's a tremendous amount of fun. And it's very educational. It's a lot of fun to research what trains ran when and where. And not only are you really into the hobby based on what we're standing in right here, which is absolutely exquisite, but you also support the hobby overall. You've been in the NMRA for years. Tell me about the support and the dedication that you have for the hobby overall. Well, you know, that's a subject, Ken, that's near and dear to my heart. I got into the hobby because of my dad. It has been a huge portion of my and my family's life. I have two daughters, both of which who grew up going to model train shows, who grew up riding trains. It's now part of their life. My youngest daughter is getting married in Nashville next week and she's getting her wedding photographs taken from the Nashville, Chattanooga and St. Louis locomotive in the city park in Nashville. Her decision, not mine. I didn't even suggest it. But so it's very, very important, I believe, for all of us as modelers to support the NMRA in general and the hobby in particular. I guess I got that backwards. Because we want to see it grow, we want to see it continue to be a vibrant hobby. And that's why I'm involved in the NMRA 2020 in St. Louis with John Schindler and Bob Amsler.  I remember it was at the NMRA convention in St. Louis where PFM introduced their sound system at the Chase Park Plaza.  So, yeah, that's been a huge part of our family's life for ever since I've been around. Brad, this is absolutely fantastic. We really love your work. I want to thank you for sharing this with all the viewers of What's Neat and I say it over and over again. This is the best hobby in the world and it's because of people just like this. This segment of What's Neat, I'm up here in Mark Twain Hobbies and I went into Joe Hudson, an incredible painter of what you call Historical miniatures. Not only does he paint military figures, but Napoleon, the incredible Hulk, you name it. What a diverse way to share the hobby. Not so much model rarity, but this is what we do in model rarity. We try to make our characters look just like what you do with yours. Now, you were showing me some pictures. You said some of these are scratch built figures and paper clips. Show me that. Explain kind of the paper clip idea of creating the frame of the human. You start with a mannequin. A mannequin, yes. And then you build up the shape of the pose and then you start layering it with different putty, which I use a bit of AIDS epoxy putty. And then I'll get the basic shape. I start shaping it and then I use different types of putty, some foils and stuff to make the bell straps and all. So you must have an amazing amount of, like, dental tools and picks to form the putty or do you prefer wooden tools? I use toothpicks. Okay. It's toothpicks, I'm saying, to points that have super glue covered on it to help stop the putty from sticking to it. Well, I know the G-scale guys would love to have some of your talent on their lap. Do you make these for people sometimes? Have you done this as a business? I used to work for Berlin Productions and I still can see masters from them and I've still got a couple of freelance masters. But I normally just do whatever the magazine is asking me to do for that particular month. Joe, this is absolutely amazing. We're looking at some of your models right now that you've got on display at the hobby shop. So those folks that want to see these can come up the Mark Twain hobbies here in St. Charles, Missouri, the suburb of St. Louis and see some of Joe's great models. And Joe, I'd love to have you on the podcast sometime to share some of your, you know, live mannerisms and explain what it is you do. There's another gentleman that comes up here. What is his name? Chris Merasco. Chris Merasco. We had him on the show. What an incredible, he's got the same talents as you have. I've known Chris for a long time. You guys are brothers. That's why this is the best hobby in the world. Thank you very much Joe for this few minutes of your time. This is awesome. And that's this segment for what's neat.  Tell me about this gorgeous model. What did you do here? Well, this was the car. You got three of them. You said from the Colorado Model Railroad Museum and you want to get them weathered up. So I think it was, I got it last Saturday night. You said you needed it back right away. So I did it about two or three days. I had to work pretty quickly and plan it all out. It probably took me 10 to 12 hours to do. I started out doing an airbrush fade on it to really knock down the blue on it.  So that's the original color to look like it had been patched. But did an airbrush fade and I even went back over with that with a zinc white oil fade. And then while that was drying, I did the roof. Those are just brushed on acrylic browns. Then from there, started doing the rust. Did the pits, then the streaking, and then came back and added the COTS label and FRA reflective striping on there. And that was pretty much about it. Obviously I added some newer couplers and did the trucks and wheels and everything too. That's beautiful. Did you say about how long you thought it took to do this? About yeah, about 10 to 12 hours maybe. I've worked a couple hours. I think Sunday night and then some pretty long, almost five hour sessions on Monday and Tuesday night because originally you wanted it back Wednesday. That's fantastic. I love how you must have masked over the blue original color before you did the fade airbrush work. But yeah, awesome job, Jeff. We love it when you weather stuff and you bring stuff over here. This one is just, it's just you outdid yourself, brother. I love this car. Thank you for sharing this with the viewers of What's Neat, Jeff Meyer. Thanks for having me, Ken. Hey guys, George from SoundTracks here. And on this segment of What's Neat, we're going to upgrade this Broadway limited M1A to a Sonami 2 sound system. Now the first step we're going to do is we're going to remove the tender shell. Now in this particular locomotive, on the tender there's two screws right here in the middle that we're going to remove. And then that will allow us to quickly remove the shell. Now once we've removed the tender shell, we're going to take this connector and we're going to thread it through the opening here so we have access and we can set the tender shell aside so that it doesn't get damaged. So in order to continue to complete this installation, we're going to take the tender and set it aside for the moment. And we're going to open up our locomotive because we're going to make some changes inside the locomotive to allow a little bit more operation. So first thing we have to do is we have to find the screw that's located here under the pilot truck. And we're going to remove that screw. Then there's two screws here underneath the cab. And these two screws will allow the locomotive shell to easily lift off of the body. Now we just have to very carefully now lift the body shell up and off and away from the frame. And you're going to notice a bunch of wires heading up into the body. And a lot of these are going to be controlling the smoke unit which we're going to be removing here in just a few moments. Now once we get our shell off you're going to see a whole lot of wires in here that are all going to control the smoke unit that we're going to remove in this particular installation. So first off we're going to take this shell we're going to set it aside and we're going to unplug each of these harnesses here that are going to the shell. So this way we have the shell now separated from the body. Now the second screw is going to be located here under the feed water heater. We're going to take the top of that off and it's going to reveal a screw right here inside of the body. So we're going to remove that screw now and grab a pair of tweezers and we're going to pull the screw out of the hole. This one we can set aside we're not going to need that one again. Now before we pull our weight out we're going to take our smoke box plate off and unplug the wires for the headlight out of the circuit board here. So we're going to unplug this harness we're going to take this and we're going to set this aside for the moment. Now our weight is free to move out from inside the shell and it just comes right out. We'll take our body shell and set it aside for safe keeping because we're going to work on this unit next. Now to remove the smoke unit we're going to remove the two screws here this front little small PCB that mounts the smoke unit and the electronics on top and we're also going to be able to remove most of the mess of this wire. So we're going to take these two screws and loosen them up. We're going to pull this up and out of the way and we're going to take our smoke unit out from underneath and like I said most of these wires are going to go away. Now we need to replace this circuit board because this is the one that the headlight plugs into but we can't just simply screw it down to the base because these two terminals on the bottom of the plug will short against the frame.  Put that in place and then now we can replace the circuit board with the screws. Now they don't need to be real tight just enough to hold it in place but the tape underneath is going to insulate that and protect it. Now the rest of this we can cut away the wires that we don't need. So once we've untangled the wires we'll go ahead and cut the wire that we don't need at this plug. We can discard the plug and now the smoke unit. That'll leave us with the weight that'll go back into the boiler and this beautiful area that we're going to use and we're going to mount one of our mini cube speakers up inside the boiler here to help distribute the sound over the entire model instead of having the sound just emanating out of the tender. Now with Soundtracks part number 810154 mini cube you'll see that it fits perfectly right there where the smoke unit was. So we're going to take a small piece of our double stick foam tape we're going to cut it to about the size of the speaker we're going to mount it to the back of the speaker here we're going to peel the backing and we're going to stick it into place. So once we've got the backing peeled we're going to place the speaker into place and we're going to make sure the terminals are facing backwards towards the model so that that way we have a shorter wire run. Now the next step is we're going to add wire to our speaker and we're going to take our purple wire part number 810144 from Soundtracks. Now while we're doing that these wires for the headlight are also going to be a little bit short so we can add a little length to them or we can just desolder them here at the circuit board and replace them with a little bit longer. I recommend a wire about 8 inches in length that'll give us plenty of room to go there and to the connector on the motor that we're going to be attaching to. So when you're soldering you want to make sure you have a fine solder a very small diameter because you can always add more but it's a lot harder to take away excess. You also want to make sure to use an electronics compatible flux and use it in small amounts because the flux will help the solder flow onto the connection. Now we can strip and tin the end of the wire before we solder the joints so simply remove about a sixteenth or an eighth of an inch of the end of the insulation off of the wire you're going to apply a small dab of solder flux onto the wire itself you're going to take a little bit of solder you're going to tap touch it against the end of your wire the flux will draw the solder off of the iron and into the joint so now that we've done our soldering we want to make sure and identify positive and negative so on the card that comes with the decoder you'll identify your positive side. Now in this particular installation I used purple wires for both terminals so I tied a knot in the positive side to identify positive versus negative. You can also choose to use two different wire colors so now we're going to go ahead and reinstall this body weight we're going to put this up inside of here and we're going to mount it back into place using the screw here on the bottom of the shell now once you get the screw hole lined up you can just simply place the screw in place we're going to grab our screwdriver and we're going to screw into the bottom of that weight and that's going to lock that plate in place now to help clean up the installation we're going to take the colored wires and we're going to twist them together so that they're paired up so we know which wires go with which. Now that will help clean it up and keep the wires from interfering in the driveline inside the body now once you've twisted the wires we can take our smoke box we can plug it back into the small circuit board up here on the front and then we can replace the smoke box front onto the body shell and now for the moment we can take this set it aside and we'll work on the chassis next so next we're going to work on the chassis the first thing we want to do is we want to remove a lot of these extra electronics that were there to control the smoke unit now to do that there is a small PCB that is located here under the cab and that's going to be where the plug from the tender connects in. Now what we want to do is we want to verify which terminals are for which purpose and desolder the wires that need to be out of the way and leave the wires such as the motor leads and the track wires that do need to be in place so what we're going to do is we're going to draw a quick diagram similar to the circuit board that's located on there. Next we're going to take a multimeter set to continuity so when you get a direct short you get a tone so we're going to take this and we're just going to run along here and make sure which terminals connect to which to which wires so that way we can make sure the wire this up properly the first time so before desoldering everything we're going to remove this black insulated piece of electronics by removing the screw we're going to take this and lift it up out of the way and that will give us access to our desolder joints now once we've determined which wires are what we're going to fill this in on this document on this diagram now we're going to go desolder the wires that we need to remove and now with our wires desoldered we're going to remove a lot of these electronics out of the way so since we've already unscrewed this one the next one to unscrew is the on off switch that triggers the smoke unit on and off so we're going to remove that screw we're going to lift that up out of the way now the last one is this isolator board up here two screws off of the front of it we're going to remove it as well now once we've removed our screws our circuitry just simply lifts out including the piece of electrical tape that's holding everything in place now look at how much cleaner this installation looks already now once we've removed all the extra electronics now it's time to wire the boiler and our headlight and the extra speaker into that circuit board so let's bring this in and remember we've got our four wires now the headlight wire is color coded red and black red is positive black is negative and our speakers we've got both purple but remember we tied the knot in the positive side of the speaker so now going back to our diagram that we've drawn up before we're going to follow this plan and now we're going to solder the wires to the circuit board when doing this you want to make sure that you've got enough wire so that you can remove the shell later if necessary so you'll want to probably about a couple extra inches so that you can remove the shell so at this point we can go ahead and cut our wires here and we'll solder them to the circuit board now once we've finished this we can put the locomotive together again so with our extra wires we can take them tuck them up inside the body shell and we can set the body shell back in place and then we can replace our screws now we can take our locomotive and set it aside while we start on the tender so now we can start on the tender now the first thing we're going to want to do is we're going to want to remove the factory installed circuit board so we're going to take our set of wire cutters we're going to cut these wires as long as we can make sure we've got enough room to add on the extra wires for the decoder we're going to put this connector aside because we're going to have to use that to connect back to the locomotive now we can simply remove this out of the body shell so there's two screws that will remove the circuit board and we can take that pull it up out of the way and then you're going to notice the two speaker wires are there also so we're going to want to cut those again as long as we can and we have our front and rear track pickup wires attached to it as well again we're going to cut these to give us as much length as we can now we can take the circuit board and set it aside the next step is we will need to make sure that these speakers are wired in series they're 8 ohm speakers but this way we can have a 16 ohm load on the decoder because we're going to take that speaker that's up in the locomotive and wire it parallel to these two speakers so we need to make sure that we don't overload the amplifier to do that we're going to have to move these wires out of the way and there's two screws here that will allow us quick access to the speakers we're going to take these out and we're going to move this plate to the side for the moment now we're going to take the wires that they've given us here and we're going to wire them up in a series manner that's going to be the decoder to the speaker positive from the first speaker's negative to the second speaker's positive and then from the second speaker's negative back to the decoder so let's go and make that change now now once we've wired these two speakers in series then we can replace the plate that holds them back in place now there's nothing left to do but wire in the decoder so the next step is to actually install and wire the decoder in place now in this installation we're going to use our TSU 2200 for steam decoder we're going to take it out of the package then we're going to take some of our double stick tape and we're going to mount it to the top of this plate that's holding the speakers in place we don't need a whole lot of tape just enough to hold it in place and this is where editing is going to come into play because this tape is hard to peel the backing off okay and now with the decoder mounted in place we're going to wire it into our plug again following the diagram that we drew in conjunction with the locomotive side and make sure that the connections match that of the locomotive now the first thing you want to do when doing that is make sure that the plug is oriented the way it needs to be when it's plugged into the locomotive or your plug and wires are going to be backwards so for this locomotive you're going to see that the side with the pins visible is going to be the top so when we made our diagram we want to make sure that this matches where it's going to plug in so that that way we don't get anything wired up backwards now when we're making our connections we're going to shorten the wires and we're going to attach them to the appropriate terminals we're going to shorten these wires because we don't need quite that long a wire so we're going to shorten these up make sure that they match and leave them at about that long leaving behind we're going to strip and tin the ends of the wire we're going to tie them together we're going to solder them and then we're going to put our heat shrink tubing over the connection to make sure that it's a nice solid and insulated connection so now that we've made all of our solder connections now is a great time to test the locomotive plug this into the model be careful to make sure none of the loose wires touch any of the live rail plug it into the model, put it on the track and then turn on the track power and verify and make sure everything works the way it's exposed to what we found during our testing was that the motor wires were actually opposite of what the decoder is rated for so the positive was actually the negative side of the motor so what happened was when I went in the forward direction my model moved backwards while my headlight was on a simple switch of the orange and grey wires made it very quick and easy to make this change now once everything's finished up and we've tested it and everything works the way it's supposed to, let's button up the model so to help keep the wiring clean I've got one of these small little zip ties that we're going to take and wrap around this harness and that way we can kind of keep all these extra wires loose so the only part coming out will be the intended part of the harness that plugs into the locomotive so we're going to take this and we're going to wrap this up about like that so that should be more than enough to be able to connect to the locomotive so we're going to cut the excess of our connector we're going to set that aside now these other loose wires that are sitting around what we want to do is we want to tape those up and out of the way to make sure that they don't really touch anything that they should to make sure that they don't touch anything that they shouldn't so we're going to fish these wires out and we can use any type of tape a simple piece of scotch tape is just as good there's other tapes like capton tape you might be able to use and what this is just going to do is this is just going to help keep these wires from floating around loose I would not recommend using electrical tape since electrical tape especially the black electrical tape comes unraveled after years and this is just something that we don't want to have to deal with so we're going to take a small piece of our scotch tape we're just going to connect this and like I said it's just to hold the wires in place and we can trim off the excess wire the excess tape now once this is done we're ready to put the shell on so now we're going to grab our shell and our two screws remember we have to fish the connector through the opening in the front of the tender so once that connector is through we can simply put the tender shell back on in place and then re-insert the two screws on the bottom of the body that holds the body shell in place and then we can push this back up and in if we need to we can pull this out then we can say now let's take it for a test spin and plug in our connector make sure the plug is fully seated and then we can push the extra wire up into the tender shell there now let's go take it for a run so before we button this thing up this is where we want to add a current keeper now the TSU 2200 that we've selected actually has a two pin current keeper connection right here so you can simply trim the insulation back just a little bit plug in your current keeper tape it down either next to or on top of the decoder and then proceed with your shell installation and there you have it we've done our installation now let's get our locomotive let's plug it in and take it for a test run so now let's test it out and make sure everything still works looks like we're all good to go so now there's nothing left but to sit back set up a few of the CVs and enjoy the fruit of your work all of the model railroad products seen in this episode of What's Neat are available through Caboose in Lakewood, Colorado or order online at mycaboose.com


A new study has found that plant-based diets, especially those rich in high-quality plant foods, are associated with a significantly reduced risk of developing type 2 diabetes, T2D. This suggests that shifting towards diets rich in healthy plant foods may help reduce the risk of developing this disease. This article was authored by Ambika Satija, Shilpa and Bhupati Raju, Eric B. Rim and others.


Good afternoon and welcome to everybody that I'm really pleased that you have joined this session to see how Dormant Kaba leverages and deploys in Cloud Foundry. My name is Adriano. I'm working at Dormant Kaba for the most thrilling projects. And in the remaining time, I contribute and maintain some open source projects. And most of them are used within Dormant Kaba too. And really often I'm an unconventional thinker. I have always the challenge, the drive to challenge the status quo. And last but not least, I'm happily married with the best woman in the world. And we have two beautiful kids. And this is Michael, not my kid, right? Yeah, I'm Michael, CEO of a newly founded consultancy called Velkly Gambiha, Swiss term for small cloud, mainly focused on cloud technologies such as Cloud Foundry. I don't have any kids but two beautiful cats, so that's something. Well, who have you heard about Dormant Kaba so far? Raise your hands. Who knows Dormant Kaba? At least the half of you should know them. OK, these digital components on the doors that you see on this conference these are Kaba locks, digital Kaba locks. I will try to tell you a little bit about Dormant Kaba a little bit. And then we switch to more technical stuff. So the story of Dormant Kaba is a long story. It starts more than 150 years ago. On the Kaba storyline that you see there, in 8062, the first locks shop opened. And on the Dorma storyline in 98, Mr. Durkin and Mr. Mantkel from the Dorma part started the journey too. We had a lot of years of experience that merged together last year, 2015, in September, to form the new Dorma and Kaba group from the Dorma group and the Kaba group. The merger has created one of the top three companies in the global market for security index solutions. With the performance sales of more than 2 billion Swiss francs and around 16,000 employees, Dorma and Kaba is active in over 50 countries and has a presence through both production sites and distribution and service offices in all relevant markets. The growth drivers that shapes our industry are the urbanization with the infrastructure that determines security needs and the number of mega cities that increases. The increasing prosperity in emerging markets with the tourism that is on the rise all around the world and people demanding protection for themselves and their property. The demographic change with an aging world population with consequences for building requirements. The increasing need for security caused by globalization and more geopolitical risks. And the more obvious one that we focus on today, the technology. For example, the whole digitization with Internet of Things, cloud computing in general, and changing business models. So like software as a service stuff. Our innovation portfolio is driven by market trends and customer requirements, technological trends and corporate strategy. Intellectual property management and product design is part of our innovation management. We are committed to investing in research and development in order to leverage on the opportunities of Dorma and Kaba and the digital transformation of our industry. We are investing four to five percent of our annual turnover in innovation and product development. One of our latest innovative solution is Exivo. This logo here, perhaps you have seen this in the Internet somewhere. But what is Exivo? To have a rough idea of what this really is, I will try to show it by a little explanation video. So now this is Kaba Exivo. Kaba Exivo is the access solution for enterprises that need an access solution but don't want to waste time on it. So how does that work? Very easily and conveniently, the doors in question are secured by electronic locking components. And you decide, quite simply, who's allowed to open them and when? The access rights of every single medium can be changed or withdrawn at any time. Your Exivo partner does that for you. Kaba's web based solution, this is a part of Exivo, leaving you to fully concentrate on your business. Or you can do it yourself. You choose which jobs are to be performed by your partner or if you prefer by doing it yourself. You have full cost control and transparency at all times. The monthly amount depends on your requirements. Once defined, it stays the same every month. Pretty cool, didn't you think? I think so. So for a company, I don't know, for those who know Kaba from earlier, this is really a big step. So from this 150 years of history, traditional company to come to such a platform, you see here on this picture, it's not just a new access control solution. It's really one platform to rule them all, everything. The whole customer experience chain is on that platform. So for example, the partner can plan the doors, he can offer them, he can order them. The market organizations, they can review the order, they can accept it. The connected factories can immediately produce the hardware and can ship that hardware, that door parts. And the customer has an immediate access to the platform, to its customer application part of the system. So in cloud native app speaking, we can say, yeah, our front-end apps are on Cloud Foundry. So all this customer, partner, market organization, administration, support, and a lot more, the most of them are a single-page application written in React. All this is on Cloud Foundry. But our backend services, our backend apps are on Cloud Foundry too. So the whole business domain stuff, all these identity management web servers, a lot of APIs and workers, all the stuff is on Cloud Foundry. Our IoT stack is completely on Cloud Foundry. So the whole end-to-end real-time communication between the business part and the IoT devices, all that is on Cloud Foundry. So messaging, signings, there is authentication, firmware update, virtual visualization, and a lot more. And you can trust me, there are a lot of security topics in this area here. And I think we can proudly say that this IoT stack is now today in production on Cloud Foundry. So yes, the whole business model, the whole customer experience chain is on Cloud Foundry. So from acquisition to lifecycle management, everything. So everything is a service, right? Everything is a service. We do not just deliver just products anymore. We deliver, maintain, and sell services. So we can say, everything is on Cloud Foundry, right? But why? Who does this? Yeah, this is the explanation, OK? Yeah, we are motivated to do everything on Cloud Foundry. It's fun, it's cool, and it's not a joke. It's really not a joke. It's seriously. We at Norma Kaba, we really wanted to focus from the beginning on the application part and nothing else. So we don't want to grow know-how in your topics like open stack stuff, or we don't either want to maintain or operate our own POS. No, we want to concentrate on our applications. That's why we were, first of all, looking for a great POS solution. And this is obviously Cloud Foundry. And then for an extraordinary partner, and not just a common service provider. And for us, this is Swisscom. So, OK, let's make a little step, OK? Can you raise your hands if you deploy more than five apps in parallel to production? More than five, OK? More than 10, 15, 20, 50, OK? Perhaps you can talk a little bit more afterwards. We have approximately 80 cloud native apps per stage. Divided in two bigger parts, so the whole business domain parts, all these front and the back end apps that are related to the business, and the IoT stack, separated. That way, all these customer or business information are not influenced in the IoT stack. So the IoT stack doesn't know nothing about the whole business part, just focused on all this end-to-end communication, security stuff, and so on. So all these yellow points that you see here on these graphs, on these illustrations, are our apps, are really apps. And these black lines are our app-to-app connections. Oh, sorry. You don't see here any services visualized. But in the numbers, perhaps, you have noticed that we have pretty much as many services as apps, approximately. And this is, for us, the nature of understanding microservices. But we have more than just microservices. We have passwords. We have other passwords. We have patterns. We have concepts. Some stuff like event sourcing and CQS gives us great power to do really magical things. Because everything is loosely cobbled, this enables us to even replace programming language, app by app, without touching everything. The 12-factor app methodology is a great starting point to make cloud-native apps. I really recommend that. The share-nothing architecture approach gives us the possibility to even fastly replace a database, a service, without touching the whole system. Because we have pretty much for each microservice app a service, a dedicated service. And to be tolerant of failure, it forces us to write reliable code. For example, if the app detects that a connection to a service is broken, we kill immediately the app. This makes the consistency of the system safe. Stuff like distributed domain-driven design. This triggers us to think in the intentional behavior of what we have to do, and not directly in data or code. And I have to be honest, this is an approach that not every developer is good in. We directly try to imagine stuff and model in our brains into, OK, I have to do this function, this abstraction, and this data. And domain-driven design really triggers us to not do this. And for everything we do, we have to be concerned really about security. Because we make security, right? Access control is important. And not just only security, but multiple layers of security. OK, let's have a look at our CI landscape. It's really more or less traditional. We have Mr. Jenkins. Mr. Jenkins, that does a lot for us right now. For example, by having access to our code, he can run unit tests, integration tests, end-to-end tests, do some reports. With the help of BrowseTech, can do this nicely, end-to-end test stuff, and then the results can be right back to JIRA, Slack, Mail, and so on. Another job is the whole deployment. So we deploy to our Cloud Foundry instances. We use the Swisscom App Cloud, as well as a virtual private Cloud Foundry installation, also by Swisscom. And both are offering the possibility to use MongoDB, Redis, Atmos, Revident Q, and our preferred App Runtime Node.js. And currently, all our apps are written in Node.js. We have six different stages. And each stage is also a Cloud Foundry space. For example, the develop stage is fully automated to ensure that our continuous integration pipeline will work. So this means every time a developer commits codes to our develop branch, this is our integration branch, Jenkins does the unit test, the integration test, and to-end test, then deploys it to the public Cloud, to the public instance of Cloud Foundry to use. And afterwards, it executes other integration tests and other end-to-end tests directly on Cloud Foundry. The test and the reuse stage, also deployed on the public Cloud, are used to review some features, some feature branches, to test specific stuff manually, because we don't have just software. We have even hardware, the doors, firmware, and so on, different firmware versions, and so on, other systems in the back end. And this stuff can really be hardly automatically be tested. So we need a sort of manual testing from time to time for different parts of the system. Then we have this sort of next stage. So I can say we have a continuous integration pipeline that works automatically, but we don't have a continuous delivery that is automatically done. For this, we have this next stage that is deployed on the virtual private. There, we choose the next release candidate. And normally, this happens every two weeks. The release candidate will be deployed there, and there we do some deployment tests, stress tests, specifically for this release candidate. And afterwards, we push this stuff to the staging, staging stage, also on the virtual private. And on this stage, we have our in-house sites. So everything that DomoKappa uses internally is deployed there, and all the doors connect there. And this is where we eat our own dog food, right? And this is just a measure to be sure that before we push this to production, we, on the first hand, we can just feel what we have coded, or if the features works. And after that, we deploy this to production, also on the virtual private. But now, let's take a look more deeper on this blue arrow, on this blue deploy arrow. Yeah. So I'm now going to talk about the whole journey Dormankava has experienced on deploying on Club Foundry. Let's first check out where it all began. It started out fairly traditional with Club Foundry Manifests and the good old CF push. So for each of these applications, the initial development cycles, there weren't like 80 apps, there were like 50.  As you can imagine, that doesn't really scale well. Well, it scales with humans, but humans are hard to scale. So we, like probably everybody else, just wrapped the CLI in a shell script. So we started writing shell scripts and scripts that execute other scripts and that grew kind of fast. And was kind of slowish when you like to do all those actions and always wait for the action to complete. It was quite a long time for 80 app deployment. So next logical step, parallelism in shell scripts can be done. So each app was deployed in a parallel fashion, but then suddenly we started experiencing failures in deployments like all over the place, try to create 50 service instances of the same type on a service broker on any provider, wondering if this will work out. So we saw some errors. Next obvious step to do was to wrap it in a higher language to get some more proper error handling capabilities. So we wrapped our shell, we convert the shell scripts to Node.js, wrap the CLI there, had some nice abstractions around the CLI so we could get some reliability in. However, still we had unexpected failures. The CLI didn't give us the proper HTTP error code. So you had to like parse the text in the debug mode of the CLI. So it wasn't like really happy days. So at the end we said, stop, we need something more sophisticated, something reliable, something flexible to do our application management. So we started looking around how to do this. And quick question to the audience, who had a similar journey thus far with deploying to Cloud Foundry? So who started with the like the CF push and then road shell scripts? One, two, yeah. And who then went further and expected the same thing in a higher language? One, one and a half, two, three, four, okay. So for those who went even further and came up with something what they call super sophisticated, please tell us because we were looking for stuff and didn't find really something. So what we did is we created what is now called Push to Cloud. So what is Push to Cloud? Push to Cloud is two components. It's our software, open source software that allows us to do in separate steps proper state definition of all our Cloud Foundry entities. So apps, environment variables, routes, everything. On the other side we have workflows so that we can remediate the state on our current deployment. We separated those for the reasons I'm gonna talk later. So let's start looking into what we call state definition. Of course, you start with your app. My app is called foobar, needs couple instances, this gram, build pack, the usual stuff you have in ECF manifest, right? We added environment variables to contextualize your application. You add service bindings. You want your app to be bound to services. This is all just you describe the state you would like to have. So you bind some routes and then we for instance have a nice feature that you can define app bindings. So you define that your app needs to talk to another microservice. It's a usual case in a microservice architecture. However, it's not that often first class citizen in application configuration. So we implemented for example like this. It's just a plug-in, but yeah. So if app A needs to talk to app B, app A in its environment gets one of the routes exposed by this app as a value as well as username, password for basic off. So by just defining I need to talk to the other app, I automatically get where to connect to and how to authenticate that I'm talking to the right person. So now we have your applications. You have one or 80 in the Dormacaba use case. And often the times you need your versions kind of matter still. We still all dream from the version that we just continuously deploy each individual microservice directly into production. But sometimes version numbers are important as they're breaking changes. So you need to somehow orchestrate what is a release that we know that works. So this is what we call a release, you just define your apps, where to find them and get and which versions to use. And now we have this release. So we want to deploy this. This is then what we call a deployment. So for all the Bosch people in the room this kind of starts probably sounding very similar. Deployment is just a definition of a target. Where do we want to deploy this release to? Which actual release to deploy? Some defaults that we can polyfill into our applications like in production we want three instances as a default and the gig RAM, whereas in development one instance and 512 max of RAM is perfectly fine. For the deployment we also do what we call service mappings. So the app developer just says I needed service binding to my foobar dash DB. And here you can translate dash DB for this deployment translates to MongoDB large. Or in the case of development MongoDB small. So this is done on a deployment level as usually when you switch deployments you kind of have a different mindset what you want to achieve there. And also we have our secret stores that you can configure. Currently only support is HashiCorp Vault. So you define where to find your secrets. So the passwords we saw before in the app connections those are gathered there. So now we have all those definitions. What do we do with it? We just feed it into a compiler. So we've written this compiler. You feed into deployment and then it retrieves all the required files and gets you a deployment configuration. This deployment configuration is basically the same data but just structured in another way that's easily machine readable. And this is a complete definition of everything you want to have happen on your Cloud Foundry. So when we now go back to the workflow components we usually have an actual state and now we changed something so we have a new desired state. This new desired state is complete with your deployment configuration. So you do your state definition, compile it, you have your desired state. The format we've chosen in a way that we can easily retrieve the exact same data from Cloud Foundry. And now everybody that does a little bit of programming should know that just dipping to data structures is kind of easy. So what do we plug in between workflows to remediate state? So how does this look like? Now comes a slide with some code. Watch out. Can anybody read this? Cool. So these are what our workflows look like. So what you see here is an example of a blue-green workflow that's available up on GitHub. I've color coded some elements. I'd like to talk about a little bit more in detail. So first up we have in green at the very top deployment config. So this is the parameter you pass in. I want to use this workflow and this is my new desired state. In blue we have our API. API here is basically your target and we put your target information up into a Cloud Foundry adapter so we can talk to one Cloud Foundry. And if the multi-cloud question is something for you this could also be just an array of APIs and then you talk to a whole set of Cloud Foundry endpoints and deploy your apps on multiple ones. Push your client in theory is completely ready for this. In yellow we have what we call workflow utilities. So your traditional waterfall do one step after another or like map function. So this was heavily inspired by functional programming. So you just map a function like create the roots on missing.root. So missing again is just a helper that gives you what you have in your desired state yet not yet in your actual state. And we have the same thing with old. So this kind of looks like a DSL but just to be perfectly clear this is JavaScript. So due to the nice dynamic nature we can make them kind of look like a DSL. But if you at any point here want to call out to your own service like your ITSM or want to write an email you can easily do this is JavaScript all the way through the workflow. So running out of time to quickly summarize we have the two components in push to cloud. We have the compiler that looks after state definition and then merges that together into a readable format for workflows which migrate your state. Of course we have a CLI to instrument the whole thing and at the very bottom we have a kind of awesome CF adapter. So if you ever have no JS and want to do anything versus cloud foundry at least have a look at the adapter. So very short, we believe with push to cloud we have written something that is very sophisticated in application configuration. You've seen the whole circle thing is we have a door macabre. We can deploy all those complex microservices easily with push to cloud. Once the state definition is there changes are easy to make and then the workflows allow us to easily achieve this. For us important was also the strong notion of having a release in the deployment. So release, it's the whole water scrum fall story, right? We usually just deploy twice a year so you need to be able to fix which versions to use and deployment obviously if you want to deploy to multiple stages. The whole thing is target platform agnostic so it works in any cloud foundry certified platform. Just said, yeah. The workflows are easily customizable. Little example here, almost running out of time. Swisscom for example just offered a new service plan with MongoDB with the newer version and instead of migrating our data ourselves we just wrote a workflow. A workflow that pushes Docker app, binds it to all the new services, create the new service of course and then migrates our data over with MongoDom, Mongo Restore and then maps the service back to our apps and we're done. So even like normal operation tasks we can use push to clouds workflow engine four. It's not just for your actual app deployments. The whole thing as we mentioned is extensible. So we've taken a plugin based approach throughout the whole piece of software. So if you want to use the other secret store than for example HashiCard Vault, your own proprietary one or whatever it's just writing a plugin. So we have APIs, just implement those APIs, put the plugin in and you're set. And it's all open source, of course. Some features with push to cloud was presented, last summit as well that we, some features that we've been working on. First of all Docker support, we've support for, you can just push Docker images instead. TCP routing is in there. Something we're really proud of is our retry and the error statistics. So even though we've pushed to cloud and retry ability so we can redo the whole kernel requests until they succeed, it would be nice to have some statistics which fail how often. So we now collect these statistics can easily provide those to our provider. And other minor things such as the cost retry handler. So sometimes one provider has a different low balance in front of their API nodes and some calls return a slightly different error status than in the spec. You can now per provider have a different retry handler. So who's all of this backed by? So we have free partners at the moment in the whole push to cloud project. It's at the HW University from Zurich. So academia is in there. We have Dorma Kaba industry and we have a service provided with Swisscom. So we have the free, I think pillars of writing cool stuff. So this is it. Thank you for your attention. Any questions? Yep, very back. So how do you avoid the manual change of your application configuration? For example, maybe I'm in operations. I see the SAP is running out of memory. So manually I change the memory publication of the SAP from that file to 1024 max. The next time I put it in, obviously it's going to be a reset to a file file. Can you just do an application with the Ops guide for us to get something in place to run it in landscape? Dorma Kaba, the Ops guide is basically that guy over there. So it's not a lot of people show, but we currently have no safeties in place there. But the DSLs, the whole thing with the workflows is don't use the ones directly on GitHub and customize them to your needs. So if you often have operators manually changing things, then just do a pre-flight check that if memory is higher set than I have configured, then take the current value instead of my configured one. Exactly this example we have Dorma Kaba enabled. Exactly this example. For instances, memory and other stuff, that was changed on target and it's higher, then we take that and do not change it back to the lower. Yeah, that was not a question. How big are your releases? How many applications do you have for release like all of them? 41, so are there different chunks? So as you have seen before, we have complete, on the complete stack, we have 80 cloud native apps. And normally if we really can target these two weeks of release cycles, then most of all there are five to 10 apps that should that changes. But if we made something groundbreaking, so on the architecture part or I don't know, a month ago we changed the whole logging library, then we have to update all apps simultaneously. So it depends, it depends a little bit, but we can do everything. Other questions? Yeah, we discussed about it and finally with that thought, okay, it will be really, really complex if we introduce some stuff because everyone would do it a little bit different and we have to deploy additional services like something like Consul or something like that. And for that to say, okay, for our use cases, we don't need it right now. It's okay that way, it's flat, but it's not so much because everything we need is the service part or it are injected in the environment where all that we already have from Cloud Foundry and our stuff is the credentials part, not so much per app, we all have little apps and these app to app connections. So right now there is no inbuilt functionality for this, but it could be done with a plug-in. Yeah, this approach also has the benefit of it runs everywhere. So we do have no external dependencies, we just use native Cloud Foundry features for what we call our service discovery. Monitoring, so you have a dashboard attached that you can see which functions and so on with which landscape currently and the state and maybe some more information. So we have monitoring, we have two types of monitoring. The one that we use really usually is the one that offers Swisscom. So the whole portal of all those apps that are there. This is a first step. And for more details, the details that come from the applications inside, we have another monitoring system that with our custom defined alerts, we can do monitoring stuff. So really, really specific to what we have there. So nothing, we have done nothing right now with the push to cloud tooling itself. But what we have done is a little prototype some time ago only with the Cloud Foundry adopter of push to cloud. We speak directly with the API and retrieve the information in a certain interval. And we can show that up through web sockets to a little web interface. But it's just to have made a little prototype. Nothing that we use right now because Swisscom does the job right now for us. Anything else? It's okay. Just if somebody interested, Dorma Kaba is hiring. Yeah? Well, thanks you for having me. Thank you.


From our studios, in the heart of Silicon Valley, Palo Alto, California, this is a CUBE Conversation. Hello everyone, welcome to this CUBE Conversation here in Palo Alto, California. I'm John Furrier, host of theCUBE. We are in theCUBE Studios. We're here with Ranga Rao, Senior Director of Product Management at Cisco Networking Group, and David Link, the CEO of ScienceLogic. Talk about their partnership. Guys, great to see you. Thanks for coming in. Glad to be here. So you guys had a great event, by the way. Symposium in DC. Congratulations. Thanks, a lot of momentum. Yeah, it was fun to watch CUBE, it was like our eight videos up on YouTube.  Talk about the relationship. You guys are meeting in the channel, got a lot of joint customers, a lot of innovation. Talk about the relationship between ScienceLogic and Cisco. Cisco and ScienceLogic have been working together because our customers demand us to work together, right? So for more than 10 years, ScienceLogic has been a strong partner for Cisco, working across various different business units. When we started working on ACI, which is application-centric infrastructure, which is the product that my group works on, we thought ScienceLogic was a perfect partner to work with. And in fact, some of our joint customers, including Cisco IT, which is a customer of ScienceLogic too, came to the table and said they needed an integration with ScienceLogic. So customers are a huge part of the genesis of the partnership, and that's what keep us going together. And the fact that we have such strong synergies from a technology perspective makes it really easy for us to collaborate. And the fact that we have both open platforms with strong APIs makes it really easy for us to collaborate. And this is the real API. We're going to get into the talk tracks around, you know, these APIs and these abstraction software layers, ACI, has kind of gone the next level. We covered that at Cisco Live. Dave, we talked before about your value proposition. You're on the front lines. Cisco obviously has this new programmability model where their goal is to leverage the value of the network, abstract away the complexities and allow people to get more value out of it. How is that working and how do you guys tie into Cisco? It's really an ecosystem of technologies and partnerships that deliver outcomes for customers. Cisco is advancing technology so fast. We've seen an innovation sprint from Cisco that's actually causing us to sprint with them on behalf of their customers. But ultimately, we've had to introduce deep integrated monitoring across all the fabrics that they support for software to find. And that includes visibility into the ACI fabrics. But it also goes through into the virtual machines, the storage layers, the operating systems, the application layer. So when you pull all of that together, that's a day two challenge for the enterprise to make sure they're delivering outcomes to the customer that are above expectations. Recently we supported support for multi-site and multi-pod. ACI fabric, we're working on ACI anywhere in the cloud. Where really Cisco's extending the data center hyper-converged solutions to deliver value propositions no matter where the applications live. So that's a huge step forward. And then it causes operational initiatives to say, how are we going to solve that problem for our customers no matter where the application lives? So that's really where we're focused, helping solve problems on that day two side of make all these technologies come together to deliver a great outcome for the end user. And so they're enabling you with the ACI to if a hyper-converge is to go out and do your thing. Yes, so we instrument all those different really abstracted components because what we have with container management, with software to find its abstraction on top of core route switch and server and hyper visor technologies that bring it together in an intuitive way. Ultimately what we've seen from the enterprise and service providers is they really want infrastructure delivered as a service. And that's really where Cisco's headed, helping make that a reality with these products. We just help bring them together with the instrumentation analytics to operate them as one system. You know, Ranga, this is a great example of what we're seeing in this modern era with the data center, the on-premises, modernization, growth of the cloud, the advent of real hybrid cloud and private cloud as well as public cloud. You guys are in a good position so I want to kind of dig into some talk tracks. One, you mentioned day two operation. So I've heard that term kicked around before. Because this kind of speaks to this modernization in IT operations, enabling an environment for network compute storage to work seamlessly. This is the real deal. What is day two operations? Can you like define what that is? Yeah, so our customers essentially go through the journey of building a network for some purpose, to deliver an application or a service to their end users. So we think of the process of them building the network is day zero, configuring the network for the particular service is day one and everything that they deal with which is a lot of complexity which is where they spend 80% of their time, 90% of their budget is day two operations which is a very complex domain. So this is the area that we have been focusing within our business unit to make our customers' lives easier with products that essentially solve some of these problems and collaborating with partners like ScienceLogic to make the operations of our customers much easier. An important part of day two operations is making sure that we provide the right kind of abstractions for our customers. Initially customers used to configure switches on a switch-by-switch basis using command line interfaces with obscure commands. What we have done within the data center as of like 2014 is brought in the application-centric abstraction. So customers can configure the network in the language of the application which is the intent. That's why we're doing it. You know, I'm old enough to remember those days of standing those networks up day one, day zero and day one. But I think day two has become really the new environment because day two operation was simply, make sure the lights are on, provision the switches, top of racks, all that stuff that went on.  Perimeter-based security, all that now is kind of thrown away. So I think day two is almost like the reality of the situation because you now have microservices, you've got apps and DevOps demanding to have the agility and programmability of the network. So I got to ask is if that's true and you got cloud over the top happening, this means that the software has to be really rock solid because it's not getting less complex, it's getting more complex. So what is science logic fit into day two? We've been focused on all these different technologies you bring together. So from an intent-based perspective, Cisco's been really focused on intent-based solutions but that lines up to a business service. The business service is made up of a lot of different technologies that can come from many different locations to deliver you an application to you where you're super satisfied with an outcome. It's delivering productivity to you, all the great things that you're hoping to experience when you interact with an application. But behind the scenes, there's a whole myriad of technologies that we instrument from a fault configuration, performance analytics and really an analysis perspective to see all these multivariate data streams coming together in a hub where we can analyze them and understand the relationships, the context of how all of those data feeds come together to enable a service. So if we know that service view, again, no matter where the service is coming from and Cisco's now supporting ACI anywhere, so that service could be sitting in a lot of different places today and we're seeing more and more hybrid applications and I think that's around for a long time to stay for good reasons, security, compliance and other reasons. You got to bring all that together and understand real time, the real time operational viewpoint of how is it now? And more so that proactive insight to know if you have an anomaly across any one of these performance variants, how that may impact the service. So is it going to be impacting the service and really help operations stay proactive? I think that's where the DevOps focuses right now. If you look at evolution of DevOps, Gene Kim was on theCUBE said 3% of enterprises have adopted DevOps. Certainly there's the early adopters. We all know who they are. They're DevOps cloud native from day one, but really the adoption of DevOps is not yet there on mainstream, it's getting there. But you're speaking to day two operations as kind of like operations, you mentioned developers. The apps that need to be built require all this infrastructure programmability. This is where I think ACI is coming to go. So you need instrumentation, so you need ITOps and you got to have programmability of the network, but everyone's talking about automation. So to me, it sounds like there's an automation story in here. If you got an instrument everything, you got to have move beyond command line and configuring, how does that fit in? How does the automation fit in? Yeah, absolutely. First of all, within the ACI fabric, we have a controller based approach. So there's a single place of managing the entire infrastructure. Today we have customers who use 200 plus physical switches being managed by a single point. That's a huge amount of automation for provisioning the network. From the perspective of managing the network, the controller continuously looks at what's going on and essentially we have a product called network assurance engine which is a second pair of eyes which will tell you proactively if there are problems in the network. But a broader automation is needed where you can actually look at information from various different silos because network as important as we as Cisco think is one part of the whole puzzle. Information comes from many different places. So there's a platform that's needed that people can funnel in pieces of information from various different places and analyze that pieces of information, figure out trends, find the things that are of interest to them and operate in a data-driven fashion. Dave, I want to get your thoughts on this next talk track around the impact of the cloud because if this happens, automation is pretty much agreed upon in the industry that we've got to automate things that are repetitive, mundane tasks and certainly the network's a lot of command line stuff that can be automated away. Value will shift to other places. But with the impact of cloud, operation, the operational side of the data center is looking more and more cloud-like. So in a way, whether the debate of moving to the private cloud versus on-premises goes away and it becomes more of a cloud operation story on-premises, multi-cloud, on-public cloud is kind of a new system. This is the operational shift. This is where all the action is. Talk about your perspective on this because this is kind of like, it's not a simple saying lift and shift and move everything to the cloud. It's I want cloud-like economics. I want cloud-like elasticity. I want all that benefit on-premises. That's day two in my opinion, do you agree? I do and I think that's sometimes lost on the industry that we have a lot of clouds that we have to serve and for good purpose, they're going to live in different places. But back to the earlier comment, you've got to then pull information into a data hub. I'll just call it an architecture of data where you've got it from multiple sources, whether it's clouds or private hyper-converged, the wireless to the end user. All these different layers often that are being abstracted, we've got to really understand how that relates to a user experience. So when we think about what are the end results we're trying to achieve, we're trying to be proactive. So among the things that we're working on from a vision perspective, instead of thinking about waiting for a system across any one of these tiers to have a fault where it tells you, I've got a problem, here's a trap, here's a log, I've experienced this problem. We really want to do a lot more on the front end, the performance analytics, the anomaly detection to get across multivariates. All these variants mean this kind of performance health and a performance score. Cisco's been investing heavily here, we have as well, jointly for some of our customers, what I'd like to see in the future, our vision, is that you rely less on fault management and more on the proactive analytics side so that you understand anomalous behavior and how that could impact your experience as an end user and fix it through automation before there is a problem. So that's a very different thought. I'd love to say our industry should, in the future, worry less about event correlation and more about predictive behavior. So that's where we're spending a lot of our time. It's like, don't look so worried about the faults, look for the goodness too. I mean, where's the efficiencies? But you have to have all these data streams and you have to understand how they contextually relate to one another to make those important decisions and recommendations. Well, you know, I've always said this on theCUBE, you can, you know, in this world of digital, you can instrument everything, so as soon as it's going to be a matter of time for seeing what everything's happening, but knowing what to look at is kind of like what you're getting at here. Okay, Raghav, talk about your perspective, because again, one of the things that Dave Vellante and I do, many of you talk about it all the time on theCUBE is we debate this cloud conversation because my opinion is it's one big distributed architecture. It's like an operating system. If it's all the cloud, they're all edges, nodes and arcs on a distributed map. So the data center certainly isn't going away. But if everything's a network connection, whether it's the edge or data center, this is you're in the business of networking, right? What's your take on all this? Because, you know, if it's a cloud operations, it's a shift from the old IT to the new IT. What's your perspective on this? So the moniker that we have been using this year is that there's nothing centered about the data center. Like you said, there are workloads that reside in many different environments, including the cloud. So customers are demanding consistent operations and consistent management capabilities across this many different environments, right? So you're right, the data center itself is turning out more to be like a cloud. And we have even seen large cloud providers like offer solutions that sit within a customer's data center, right? So that's one area in which the world's evolving. And another area is in terms of all the tools that are coming together to solve some of the operational problems to be more predictive and more proactive. Yeah, you know, I like toot our own horn sometimes. Stu Miniman at Wikibon coined the term private cloud years ago, and everyone was throwing hate at him, you know, on the internet. What's this private cloud nonsense? That's what's happening. This is a private cloud, it's a hybrid cloud, multiple clouds, you have public cloud. And again, you're going to have multi-purpose, pick the right cloud for the workload kind of environment going on.  So guys, thanks for coming in and sharing your insights. I really appreciate that. Before we go, take a minute to get the plug in for what you guys are working on, give the company update, what's going on, the hiring, revenues up, what's happening. Give us a state of the science logic, what's going on. So we had a great first quarter, the best first quarter in the history of the company. The health of the business is good. I think the underlying theme is the transform of infrastructure is causing a lot of people to rethink the monitoring tooling as to how do we need to manage in this new operating environment? You mentioned DevOps. I think the real key there is the developer really wants to have the application be infrastructure aware. And he needs good information coming from not 50 places, but from a trusted place where he can make sure the application knows about how all the infrastructure that's supporting it, no matter where it is, is behaving. And that's really the wind behind the sails driving our business. We grew quarter over quarter sequentially with our subscription over 100% in Q1. So we're really thrilled with where the business is headed, excited about the momentum. And this is a really important partnership for us because everybody uses Cisco. All of our enterprise customers, service provider, government customers, Cisco is embedded in virtually every customer that we work with. So we have to have the best support, kind of that thought leadership of support for our customers, for them to entrust management of those core applications through our platform. Right, give the quick plug for the data center networking group. What's happening there? What's the hot items? Give the plug, quick. So very quickly, I think the journey that we have been on is ACI anywhere to take ACI and its management and operations paradigm to many different environments. We introduced support for AWS earlier in this year. We are working on support for Azure and soon will have support for Google public clouds. In all these environments, we want our customers to have consistent experience. And the way we get that is through solutions, working with partners where we offer consistent solutions across all these environments for our customers and working with science logic as a very important partner to solve problems for our joint customers. And you guys have always had a great channel, great ecosystem, not new for you to partner. Yeah, we have like open APIs, open platform, 65 plus partners that we work with. So all customer focus.  What's the biggest wake up call that customers are having with respect to the old way of doing networking and the new way? Because clearly everyone has come to the realization that the perimeter based security model and static networking has to be more dynamic. What's the big wake up call that you think customers are seeing now with this new modern era? I think customers are realizing more and more how important technology is as part of their business. Sometimes it even drives the business and helps customers make decisions on what's the right path to take for their business. So with this applications become really important and the nerve center, which is the network that supports the application becomes really important. So customers are demanding us to build the best network possible to support this modern world that's continuously evolving. So. Dave, do you think a stab at that customer wake up call? What's your perspective on this? What's the big off from your experience over the years? You can't use tools that were built 20 years ago to continue operating global networks. So we see a lot of the industry, it's about a $10 billion total adjustable market changing over because the market fit of the old tools that people have relied upon for many years aren't solving modern problems. Well guys, thanks for the insight, appreciate it and good to see the partnership doing well. Thanks for coming into the CUBE studio. We have Rango Rouse, senior director of product management at Cisco Networking Group and David Link, CEO of ScienceLogic here for CUBE Conversation. I'm John Furrier, thanks for watching.