.NET Rocks Live – Containers & Microservices Panel
Leroux Bustamante, Michele
Rendle, Mark
Hall, Ben
Join Carl and Richard from .NET Rocks as they discuss the co-evolution of container technologies and microservices with panelists Michele Leroux Bustamante, Mark Rendle and Ben Hall. Is it all about Docker, or are there other products to consider? What do microservices and containers have to do with each other anyway? What makes a microservice different from a service? Is this still all about the cloud, or do containers and microservices make sense on-premise? Bring your questions and be part of the recording of a .NET Rocks episode!
 Hey London, it's Dotnet Rocks! Welcome to the Dachlands! This is the end of the second day at NDC Oslo. We do a panel discussion in front of a live studio audience. We're generating the Super besser! The show audience would love it! that we have this little thing that we call better know a framework so roll the funky music. Alright, what did we learn? So all the times that you've ever you know what happens that if you listen to the show that there's this music which created by my friend here but we never hear it when we actually record the show. So right if you ever hear us talk about how funny that music sounds is that's live. All lies. It's just like filming a Star Wars against a green screen. It's the green screen audio effect. Exactly. But it is kind of cool. Alright so then you say. And then it's also these are also edit points so if you've ever wondered why everything sounds so smooth on a show it's because we have editors. But you mean you're not going to keep this in? Yeah. I'm disappointed. Yeah, no it's only for people who are actually in the room. They never get to. So you're going to excel in this show. Yeah, an edited version of it. So it's a Tuesday show so that's Brandon right? Yeah. Right this is Brandon's show. So Brandon is the editor for this particular show. I would say hi to Brandon. Hi Brandon. Hi Brandon. We love you Brandon. You even make us sound smart. Which is not easy to do. Alright so go ahead. Okay you ready? Alright buddy what do you got? Well I went I you know I look for things that are trending and this is one of them. It's called idunvis.com. Nice. You've done it. You've done it. You've done it. Alright. You've done hired the hit maker. That's the reference you're making. Yeah well idunvis is a service where you reply to an evening email reminder that you get from it with what you did that day. And the next day you get a digest with what everyone on the team got done. Now I know this is like a service that really costs like five bucks a month per user but it's not that I'm giving them a plug. I'm saying it's not a bad idea. I mean you know doing a sort of an email digest is something that we could probably all do just on a Saturday while watching TV. But so it is a pretty cool idea and I don't know if anybody else has something like this or has written something or used something like this but I thought it was pretty compelling so that's why I brought it up. idunvis.com. Love it. Who's talking to us my friend? Grab the comment. Another right of point. I grabbed your comment on the show 1125 the one we did with Seth Locker back when we were in Nebraska talking about Docker for developers. I think it was one of the early Docker conversations we had too because he was very much a Linux guy. So rather than you know he didn't have any of the issues around Windows and things with it so we were coming at it from a Linux perspective. But some of the comments on this were super awesome. And the one I wanted to refer to is from, let me say it again, and Johan Obrink gave us this great comment spot from nine months ago or so when the show first came out. He said in the show you mentioned the lack of good tooling for managing the deployment of Docker containers across virtual machines. We recently started using Tutom. That's T-U-T-U-M dot C-O. It allows us to manage containers, private Docker hosts and cloud providers so that containers can be provisioned across Azure, DigitalOcean, AWS and more. By the way I've gone and taken a look at Tutom. It's currently free under preview and it really does a lot of stuff for you in terms of just managing containers symmetrically, no matter what platform you're working from. The containers all perceive it as if they were on the same local network which makes setting up redundancy really easy. Elastic search for example will automatically distribute all indexes across all machines without being aware of course that it could be across literally multiple cloud hosts if you want them to be. We can also select the best cloud for each service, DigitalOcean for disk intensive operations as you use SSDs, AWS if you want to use data from S3 and so on while providing fallbacks if a cloud provider could go down. Could that ever happen? Never. Never. Never. That's just crazy. We don't go down. Anyway, I thought it was a great comment. Johan thanks so much for providing that comment. I will take a good long look at Tutom. I hope others do as well, especially while it's in preview. And at.NET Rocksmug is on its way to you. If you'd like a.NET Rocksmug, write a comment on the website at.NET Rocks.com or via any of our social media platforms. We post every show to Google plus and Facebook and if you write a comment there, we read it on the show. We'll send you a mug. And of course you can follow us on Twitter. He's at Rich Campbell. I'm at Carl Franklin. What's the date on that comment? That comment is from nine months ago. So it was probably right after that show got published which was April of 2015. Yeah, I just wanted to keep that in mind as we talk to the panel today and see what we think of that. And I guess that means we need the panel to introduce themselves. We'll start way down at the end there. Ben Hall, why don't you tell us everybody what you do? Cool. So I'm the founder of a company called Ocelot Upwall. We're a software development studio. So we help companies deliver training sessions on topics such as Docker. And we also build our own internal products. One of which is Catecoda, which is an interactive learning platform for software engineers who can learn things like Docker in your browser without any downloads or configuration. And Ocelot Upwall is a sophisticated code word for a pussy riot. Okay. Completely, completely. For those who haven't watched our chat as we discussed this morning. Okay, Mark. You're up. I'm Mark Rendell and I'm a professional podcast guest. And you are among other things. Didn't you say the word Docker? I should probably say Cloud Lens, shouldn't I? So I've been running something called Zudio, which is a terrible name. So now I'm working on something called Cloud Lens, which is basically the next version of that, which is ASPignet 5 and Docker and Azure and all those good things. You have an impressive setup there that we talked about in our last show. Yes. So I'm still just about to actually put it live in beta. Wow. Awesome. Michelle. I'm Michelle DeRuz Monta. I have a consulting company called Soliance. We do a lot of migration to cloud, focus on distributed architectures. Now microservices, previously other things. And spending a lot of time with service fabric, Docker and I had to say Docker. Docker Docker Docker Docker. And I have a product called Snapboard that I'm actually also deploying to a microservice platform. Wow. Wow. Wow. So you'd be surprised. Why is he surprised? I don't know. Thank you. Nice. All right. Well, who wants to go first? I mean, first of all, any reactions to that nine month old suggestion about managing containers? Well, yeah. So some people it might sound surprising that Tutum is still in beta. Once you immerse yourself in the Docker ecosystem, nine months is really not a very long time. But no, I have, I looked at Tutum and they appear to provide a very good hosted service. If you want someone to manage that infrastructure side of things for you. There are open source tools that do roughly the same set of stuff, but that you have to kind of provide the infrastructure to run the servers for that sort of thing yourself. Right. 500 different ones. And there are 500 different ones. I mean, I'm for cloud lens, I'm using one called Rancher, which is very nice. And they release, they do a new release once a week and they just broke their version numbering because it was based on week numbers. So now we're going back to one again. Oh, yeah. But no, that's a great product. That does a similar thing. I can run one kind of master server in the Azure North Europe data center. And I could run it in Amazon or Digital Ocean and then I can run nodes in all the Azure data centers, which is something that I have to do. But as far as they're concerned, they are all a single network. It does it, set tunneling between things. And I can do a push to the Docker registry and 19 data centers will update themselves with that new image. Just automatically. I just have that set up as a hook in Rancher to do that. So that's what I'm using. I'm sure that I think Ben wrote his own thing. Probably. Because of course he did. And based on the container ecosystem. Did you write it in Go? Yeah. A little bit. A little bit. That's fine. It's proper Docker. It's not proper Docker unless it's written in Go or maybe Python. We didn't. We talked to you today, Ben. And of course the show was published weeks ago because time shifting. And I don't know if to them was one thing that you mentioned, but no, Docker to Tom's just been acquired by Docker said I've now bought it in house and part of the team and Docker have to Tom. They also have a control plane offering and which is more for on-premise and in-house offerings. And I think that's where they position in it. And I think that's where they're going to be focused on the cloud. And about very cool, but there's so much activity like Rancher, for example. It's also a great company and a great product. There's a huge amount to be aware of and it's hard to keep track and know what's best to actually solve your problem. We developed our own because we don't have the same problems as what most scalability companies do. And we've got. You are a special, special flaw. It's not a traditional website problem. Right. Because we're not just scaling traffic. We're building and delivering virtual machines and environments. And so that's why we decided to use the API directly, which it's very powerful. It's very strong. It's got some great wrappers. But for most problems, I'd recommend going to some like Rancher or Kubernetes. Or beyond. Right. Yeah, exactly. A little bit depends on. So there are companies, different companies at different stages have different problems. So I mean, Google made Kubernetes to solve Google's problem. And Google's problem is we need to marshal millions of CPUs and servers and get them all to work as though they were one thing. And we'd rather not employ 100,000 people to do that. My problem is I would like to run as few servers as possible. Yeah. I would like to run my costs down. And so Rancher works well at that. And it sort of scales up to this level. Kubernetes, MesaSphere, things like these schedulers are designed for when you're just throwing huge amounts of processing power and money at getting things done as quickly as possible and as easily as possible. But only so far easily, right? Because it's not really a pass. It's still you have to manage it. You have to throw resources at it until you get to the point where you go to a hosted provider. Yeah. And that's the interesting part because I probably deal with a lot of customers that are looking to move to microservices and not have to do all the work. So while they're interested in some of the lower level, they're more interested in throwing money at that problem within the services space. And a big part of that is just because they don't have the people that know this stuff yet. And so it's too much of a challenge to undertake to try to think. We can think design. We can think microservice. We can think building containers and distributing them. We understand the networking. We understand all of that stuff. But we want somebody else to make sure it's up. It's healthy. It recovers. It gives us information about the state of the whole system and so on. So it's an interesting problem because there's so many layers. And then when you're a developer, you just want to do stuff. So it's kind of fun. It's a cultural difference, I see. And I brought this up with you, Michelle, and I also brought it up with you, Ben, today, which is that in the Linux world, the focus is on control. We want all the control we can get, so therefore we need to know the stack all the way up and down. And when something doesn't work, we can swap it out. We like having that low-level control at the expense of the time that it takes to get up and running. The expertise, as Michelle was saying, versus in the Azure world, in the service fabric world, all of that stuff is sort of just handed to you with a remote control, so to speak. So I guess it's a difference in culture. Well, some of it comes from, if you think about just culture and history, I remember back in the day when I was doing mostly pre-dot-net C++ development, and then I took a hop over to the Java space, Java, Oracle, Linux, Unix, really, and building a PaaS operation based on that stack. Now, I wasn't obviously managing all of the operations without help because I was new to that space, but I was responsible for it. And what I learned is that it's a rite of passage. I mean, I'm not saying everybody's like that, but it does feel a lot like there's just a raw sort of, I don't even want to say youthful approach, but it sort of feels a little bit like that. I just want to dig in and do stuff and get things done and figure it out. And that sort of mantra felt very strong back in the day in the Java timeframe, in that timeframe for me, in working with Java. Maybe I'm just saying that because nobody wanted to help me when I went on the list. But because when you go to the.NET space, you would see immediately there's like five, 10, 15 different magazines with people writing articles and all these resources, everyone else is like, yeah, figure it out, dude. Read the manual. Call me when you're digging into the low level, I want to edit your bits that are deployed on GitHub, and then I'll talk to you. Mark, you have a foot in one foot in each side of this camp. I mean, you've noticed that cultural difference, I dig it. I'm certainly moving to, well, I'm running Linux on my actual work laptop. Is that a self-loathing thing? Do you know the funny thing? You lose a bet with God. I don't have enough. My laptop is old dual core and eight gigs of RAM, and it really isn't up to running. But that's a ton of power for most Linux instances. It is, but when you're running 12 Docker containers to spin up your kind of microservice cluster that represents your site, and you're doing that in virtual box and controlling it from Windows, it flakes pretty quickly, whereas you do it if you've actually booted directly into Linux, and it's using like a quarter of one CPU to do that, which is good because it means that all the other CPUs and all the rest of the memory is there to open an extra tab in Chrome. So true. Do you think that's angry or anything? No, not at all. But it is funny. I know exactly what Michelle's talking about. If you have a problem with Windows, you can go on to server fault or Stack Overflow, and you can find the answer to that question there. If you have a problem with Linux, then the answer will be 18 levels of greater than indentation deep in a Piper mailing list entry from 2009, which is telling you to go and edit, slash et cetera, slash something dot D slash something dot com. And you're supposed to know where that is. Yeah, you've got to find that. Which was written by a 13-year-old brainiac, right? Exactly. It was written by one of the kernel maintainers, and you've got to do this on a machine that's running in a cloud, and you've only got SSH access to it. So you log in, and then whoever created the cloud image didn't put your editor on there, so you're having to use nano or Pico or something to edit the file. And you've got no idea how that works. And you are just going, I really miss RDP at this point. I'd like to be able to log in and get a desktop. Is this the one with nano? Nano's good. It's solid, and it's easy. Yeah, but you like breakfast burritos. Okay, good point. I'll give you that. I wish I could drop this mic. Yeah, you have to whack your head on the table. It's right on your head. It can probably add it in at the time of the fight later. We could do all of those things, actually. You could fake it, just tap the thing. Yeah. Well, I feel like we've spent a good 15 minutes just talking about the container set. We're also supposed to talk about the microservice side of this whole discussion, just as a new model of building applications. Are they really that different from good old SOA? Yeah. No? It's the same stuff. WCF from microservices. It's an evolution of that mantra. It's an evolution of those principles, but done in a way that sort of evolves to additional principles. I like to look at it like everybody hates buzzwords. You hear microservice and you want to kill yourself now because it's everywhere. Or multi-family. Right. Or a number of people. I wouldn't include you in that. It's okay. But you hear it all the time, but what really is important is really the underlying change in how people will approach building systems, and you might argue that it's forcing people to do things better because it forces you to think about upfront, why don't we actually think about the domain? Why don't we actually break up the services so it's manageable to deploy and update? It makes so much logical sense that you cannot deploy monolithic things. We used to think of monolithic things as a single executable, but I see websites with maybe five, six, seven different API endpoints, but each of those has so many assemblies and so many crossing waves of shared code, and then the database is just this one monolith. It's literally impossible to update that. It's literally fearful to update that. It makes a lot of sense to change how we think. How far you go micro is completely dependent on the kind of thing you're building and where you want to get to, but the principles are solid and it helps you to think that through. Do you remember five years ago, our friend, Javall Loe. Every class is a service. Every class should be a service. This was his mantra, Javall Loe. No, it's true. Was he right? He said that before microservices, the term was, I think, really wrong. I brought this up with Ben today, which is it's not that the class is the boundary. It's what it's doing, the domain job. Right. Well, then it's not a class. Every service is not a microservice, but every microservice is a service. You still have to think in domains. There might be a single thing that is just a cache, Redis, and that's a service with data. Then there may be a single thing that is just an identity server with data. That single identity server might have three APIs, three services within the construct of that holistic feature area. But you really want everything to do with identity in that server. All that is updated together. All that is a unit of thinking as a team to, can we deploy this and not affect the rest of all of our products that depend on it, that kind of thing. You have to get out of the thought of every service equals microservice, every API equals a microservice, because that's too granular for a lot of things. You still have crossing database relations that need to be somehow collected under maybe several APIs, but grouped together and hopefully safely separated from others like it. We're going to do questions from the audience, a little different tweet at Carl Franklin. I will read your questions because we don't have an audience microphone. Sorry about that. That's what we call an edit point. I wrote a blog post about a series of blog posts because I made my new years resolution that I was going to write a blog post every day. So I wrote three blog posts. That's ambitious. No matter what. It lasted three days. It lasted much longer than my diary. I'm going to open a gym called Resolutions and for the first two weeks it's going to be a gym and then it's going to turn into a bar for the rest of the year. I'll sign for that. But no, I wrote a post saying do one thing and do it well, which was born out of frustration with the Azure Storage SDK, which has got so complicated over the years and talks to Key Vault and talks to all these different things. I was just kind of like why don't you break it out because all I want to do is upload a blog. Right. So get the bit that does blogs and release it as your blog SDK and as your whatever. And I don't mind if each of those SDKs has a dependency on a core package, but you could fix the bug in the blog SDK without us having to wait for Key Vault to release a.NET core version of that. Anyway. And then I sort of took this a step further and said microservices and I said do one thing with microservices. And I gave an example from my project where I actually use a microservice to do JWT verification. So JSON web tokens. JSON web token, you've got three parts. The first bit is a base64 encoded metadata about the token. And then in the middle, you've got a base64 encoded JSON string, which is all your claims. And then the last bit is a hash created using a private key of that middle bit so that you can't change the token. So the token has to, you know, it's been issued by your authenticated server. And you can write libraries for this and all this other stuff, but I've got, you know, multiple containers running on the same machine. And so my ASPnet5 authentication process just bounces that as a string across to this microservice, which has got two endpoints. And it's got verify. And if it's okay, then it gives you back the JSON of the claims, which you can then put into your claims principle. And if it's not, it bounces back a 403 saying that's not right. And I'm sure that someone in the audience, hello, will tell me the 403 is the wrong status code for that. And the thing is, people were going, that, you know, that is, it's a class and it's a method call on a class to verify a JSON web token. Why would you do that? Why would you split that out into a microservice? That's just stupid. And so I had to write another blog post to prove how clever I am. Where I said, okay, at the moment, I've got an X509 certificate that I'm using to verify this thing. And that gets into the microservice in this way. But I might decide to change that and use Azure Key Vault and pass the thing across to there because that has an API, which you can pass a string and it sends you back an adapter. So it is, it's essentially, it's a replaceable, instead of doing dependency injection, I can do use a different container with a different service inside it with the same API. And I can switch around. If I've got some services running in Azure and I want to use Azure Key Vault, and I've got some services running in AWS and I want to use their Key Vault or I want to use Hashicore's Vault tool, which is extremely good as well, I can, I can switch these things out without having to recompile every single service just because I've changed the way I'm doing JWT, generation and authentication. That's a perfect example of why you should be decomposing things in the microservice. But it raises something interesting, which is the security issues around going microservices beyond the obvious stuff that people worry about with multi-tenancy and, you know, container segregation and networking and so on, isolation. But it actually comes back to, if you think about services, boundaries as something that always must be authenticated and authorized in some way, and if you adopt the modern topology for identity and authorization, which would be token based across all the tiers, then now we have possibly more hops than we used to if we're doing composition that goes deep that needs to be authorized, that now need token validation. Where's Dominic? Is Dominic here? I know. No? No. No. He's probably doing it, Tom. But, but, but see, this is the issue though, is that, you know, there's overhead with that. It's not too much in a traditional environment where you maybe only have two hops for the round trip from top down. But the question is how much is too much? I don't know that we can answer that question right now. I mean, I think that perhaps the methodologies around how we protect things that are, you know, behind a network might have to change. But token based is how we deal with it today because we're standardizing on APIs, which have traditionally less hops before you get back to the, to the front. We start breaking things out smaller and have more hops and more token validations. Now we're going to have to start benchmarking what's the right approach. Is it okay to say, well, this is in a private network and there's zero chance, but, but see the security person in me says no, you can't ever say that this might not be exposed. And if you don't protect it at the software level, then somebody exposes it and now you're screwed. So not okay. So there's, there's a lot to think about there, right? It's a design issue and it's a performance potentially, you know, you know, you know, performance based concern. Yeah. But it could evolve to maybe different types of validation, perhaps maybe it's not going to be asymmetric, maybe it's got to be symmetric and we go back to H Mac or something like that, just something. So, but yeah, I mean, the example of hello, can you verify this token for me? And yes, I've done that. So obviously you want to do that over IP sec tunneling. And you want to do the token server can't be on any kind of public IP address. It has to be on an internal only IP address. But yes, as soon as you get into things where you've got a big fabric of 32 hosts and messages are bouncing around all over it. So that's now hitting the real network rather than just an internal Docker bridge. Then yeah, you've got another set of issues. So at which point I would say, okay, so now we need to solve that problem as well. Yeah. But if I ever get to the point where I'm running 32 servers in every data center, I'll just pay someone to solve that problem. Yeah, I'll find somebody smarter. Yes. Good one. I'll pay Troy to come and sort out. Nice. Hey Richard. Yeah, buddy. I'm going to be that happy time. It's time to announce that I have no joke today. Well, everybody's very excited about that. Oh man, rough, rough crap. It's actually time to give away a component one studio to one lucky member of the dotnet rocks fan club. First, let me tell you about Grape City active reports. The first product we ever advertised on dotnet. That's a long time ago. This is the reporting platform for all your business needs, design, publish, view, print, and export operational reports such as invoices, expense reports, tax and government forms, as well as strategic and analytical reports such as sales performance, budgeting and revenue analysis. Active reports gives you the operation and flexibility you need to turn your data into informative pixel perfect reports across the enterprise. Nice. So who's our winner? The winner is George Britton. Congratulations George. Good to meet you. You get a real clap. Not just a golf clap. Real clap for you, sir. Yes, indeed. And George just won the component one. Excuse me. That's why we have editors. For all about. Because of your wind. Yes, because of my gas. And George just won the component one studio from component one in Grape City. And if you don't know what we're doing here, go to.NETROX.COM, click on the big get free stuff button, answer a few questions and join the.NETROX fan club. We have thousands of members all over the world and army of members in fact. And every show we like to give away stuff from our sponsors and every December we give away a $5,000 technology shopping spree to one lucky member of the.NETROX fan club. But you've got to sign up to win. We've done it four times already. Yeah. And we also like to ask our guests, guys, if you had $5,000 to spend on technology today, what would you buy? Michelle. Oh, come on. She just did this earlier today. I just did this earlier today. I know. Make us something else. I got to think about it. New toys. New toys. More toys. There's so many. So many toys. I want a recording studio. Do you really? Wow. In my office. Okay, go to soundsuckers.com. Okay. And you can get a four by six isolation booth for five grand. Perfect. There you go. Oh my God. I hit the five grand for a change. You did? Well done. I'm normally way under. When do I pick it up? Mark. Hello, Lens developer kit and Adele Precision 5000. That was easy. Yeah, boom. That's over five grand, actually. Yeah. Depending on how you configure the Adele Precision. If I don't pay Adele for the extra memory and I go and buy it from Crucial, then I keep it down under the two. Yeah, at least then it's homework. So yeah. But yeah, maybe the whole Lens Dev kit. 3000 bucks, US risk like that. That's if they feel like giving it to you. Have you tried to fill in the form for the HoloLens Dev kit? No. They ask very specific questions. Yeah, like are you in the US or Canada? Oh. That's it. They begin there, but they're very keen on you have apps in the wild built in Unity. That's sort of their barrier to entry. I downloaded Unity. Does that count? How always counts. I've got a book. I play Kerbal Space Program. That's Unity. I've got a book. I've read it. I tried putting it under my pillow to see if I absorbed the knowledge. See, we go straight through. I made the little bar go around the screen. I have a game I want to write. Not for HoloLens. I want to do the HoloLens thing where you draw in your route on a map and then put your HoloLens on and go out for a run and it puts coins along your route. You just run along and every time you run past a coin it goes, there's a problem with that. It doesn't work outside. I know, but yeah. Sorry. It's just version one. The future version. I know. Fine. Yeah. I'm going to put it in your hands, hun. I wish I did because I'm not going to actually do this stuff. Ben, what would you buy with five grand? So I was looking at Seb's new massive iPad and that looked pretty cool. Hold that thing up, Seb. Oh, is that the iPad? Holy crap. That's the giant iPad. Yeah. The iPad that thinks it's a surface. Wow. Pretty much. It comes with its own $500 pen. If you see that in the shop next to the iPad Air, it is two iPad Airs stuck together. Wow. It is literally twice as much. Wow. Gigantic. It's huge. And it's running iOS, which is just a complete waste of all that processing. Well, I appreciate Apple equipment is expensive, but I don't think that's five grand. Oh, it's when you had a HoloLens. All right. We got some questions from the audience. This is from Ollie. How would you fix the performance outliers in microservices, which are a standard problem? What? Performance outliers. Ollie, I think that requires a little explanation. Raise your hand. There it is. Go ahead. Oh, no, not you. Basically, you see, Microsoft says, well, when you have the Microsoft service, you have to be able to do that. So that's an availability problem, not really performance. Okay. Anybody who wants to answer that, just repeat the question, please. Are you talking about the number of hops per se? Like in terms of distributing densely across the nodes, that's, I mean, additional availability. So what are you referring to? Introducing more opportunities for partition. Partitioning. And for a service to go down. Therefore, all the other services that depend. See, I really want to give the position some so that if you take a service that's three nine, can you just repeat the question for us? The question was, if you've got a service that's three nines and you break that down into two services. Three nines. Nine. 99.9% uptime. Uptime. Yeah, uptime. Yeah, uptime. Yeah, availability. And you split that into two services. Then have you introduced, you know, do you now have? Have you now doubled the risk of downtime? A 99.8. Yeah. Or have you got six nines? Yeah. Which, no, you haven't got six nines. If you split that into 15, have you got an infinite number of nines? So if you need that kind of uptime availability, then obviously you have at least three instances of each service. And this is what schedulers like Kubernetes and MesaSphere and Fleet are for. It's really, really just kind of maniacal, pathological monitoring to say, I need at least this many instances of this service running. And then the other thing that you need to work out is how the communication between those services happens. Because you can do microservices that talk HTTP to each other. You can do microservices that talk native TCP protocols like Protobuf and whatever. And you can do microservices that talk over a distributed bus like ZeroMQ or Kafka. And at that point, you know, you just have to hope Kafka doesn't go down because if Kafka goes down, then you're down for days. But yeah, you know, this is really more of a philosophical argument about how reliability works. Yes. And probability as well. Well, I mean, that's an element of it. You can play that math game if you want. Probability is not cumulative. Right? Yeah. You have a 50-50 chance of flipping heads or tails every time you flip. Yeah. It doesn't matter how many times. Flip ten heads in a row. Right. You still have 50-50 chance of heads the eleventh time. Right. But you still have to deal with the same issues we talked about earlier, which is I don't care if it's a microservice or an API today. You have to, you know, build resiliency into your application. You have to have retries and back off retries at every single node that you call. And redundant. And you have to have redundancy. Use poly. And fail over capabilities in place. And, you know, this is how we should already and I think aspire to design systems today without microservices. When you have microservices, you're just more acutely aware, I think, of this fragility. Yeah. But then this is where you get into the philosophical element. You have to build one monolithic thing that never goes down no matter what, where you build a whole bunch of things that when they go down, you don't care. Yeah. Because the service isn't actually down. The analogy that's just popped into my head is if you've got an aircraft carrier and it gets a hold in it, then the whole thing sinks probably. Right. And everybody drowns. Whereas if you've got 50,000 rowing boats and one of them gets a hold in it, then one rowing boat goes down and probably the people who were in it can climb into one of the other rowing boats. Yeah, but you should see the gun on those rowing boats. Oh, man. Particularly if you build those rowing boats from six inch thick steel. Yeah. You got off the aircraft here you took part. Yeah, so yes, you introduced the possibility there are more things that could disappear, but at the same time, each of those things has fewer moving parts. Okay. And we'll move on to another. Fewer vulnerabilities. We'll move on to the next question. It's from Tom. How do databases work well with microservices? Microdatabases? Nice. Yeah, why not? If you're breaking down your application, like we were talking earlier on about the fact that what was a bounded context has now become a microservice. If you can separate your business model and your logic out into those things and create those boundaries, then why would you want to ruin that all by putting all the data in the same Oracle database? Right. And you give yourself the possibility to go, right. The financial data obviously needs to be in an asset compliant transactional database replicated across multiple nodes and backed up every night. So, you know, as you're a SQL database or Oracle, if you hate yourself and like deploying DBAs. So true though. You're never sponsored by Oracle, are you? Yeah. Not anymore anyway. Yeah. There's the Oracle licensing model. How much money have you got? And for the privilege of updates, we will take X a year, right? Yes. And if you have no money, you can have MySQL, which will teach you to have no money. Postgres people. Come on. But yes, you can kind of go, right, so this goes into this. With microservices, one of the awesome things about microservices is you can go, you know what, there's a really nice node library for doing that. There's a really nice go library for doing that. And a brilliant Python library for doing this kind of machine learning sort of thing. Yeah. And so you use the right tool for the right part of your service. And it's the same with your data. You can have, you know, some stuff needs to go in a SQL database. Some stuff can go in a document database. Some stuff can go in a Y value column store, like table storage or the central. And paraphrasing from Ben from your show earlier. You do want to let stuff to be stored outside of the container in something a little more durable than any given container. And when I put my IT hat on, that doesn't preclude reliability, backup, like all of those things. Just because you have stuff stored in different locations in different ways doesn't mean it isn't still valuable to the organization and needs care and feeding. It doesn't have to be a DBA. It just has to be somebody who knows what files. Yeah. Or the last guy standing next to the database when the last guy left. You. You're it. I think the other model that is introduced though is the partitioning model. For example, I like what service fabric is doing around partitioning. The idea of partition early because they'll handle it. So, you know, you think A to Z or you think, you know, one through 100 partitions based on whatever it is, country, states, you know, last names, whatever the case may be. You break it up as far as you can up front and then you let them handle saying, oh, well, you only need two servers. So we'll just distribute across the two or three in the cluster. But now when it's time to, you know, spread out, you've already done the job. And in the meantime, they have a naming service that can go ahead and do the queries and find the right partition. So it's done right up front. And that's the right way to do partitioning. It's just that it forces us to think too early about that. But when you start thinking in micro, you can start thinking in micro around that as well. And now it becomes a little bit more manageable. Everything becomes manageable. The part that feels nerve wracking is the potential of the chaos monkey in the middle because there's so many moving parts now. So now we do the better job around the moving parts. I also want to talk. I find that relatively few people think about partitioning chronologically. Like as a guy who built a lot of e-commerce sites, like keeping more than the last seven days of data in the very fast data store is dumb. Right? Like it's just no reason. The data is not going to change. It's journal. I'll call you from there. Yeah. Get it out of there. Get it out of there often. It can't be one day because there are reconciliations. But it only needs to be a few days. And if you just get into this habit right at the beginning of we have a rolling window of time and then when the arbitrary definition of a month ends, then we pull that off and do things with it. But the vast majority of that data never, ever, ever, ever changes. Put it in a read-only state and it'll turn out it performs awesome when nobody's allowed to modify it. All right. We only have a few minutes, so I really want to get to some of these other questions here. Is there a Windows, and this is from Ian, is there a Windows story on microservices for those of us who have avoided Linux thus far and quite like it that way? Michelle, I think that's your, your, your house. Well, there, there is a in-progress version of that. So we have a Windows Server 2016 Tech Preview 3. Save that fast five times. I dare you. And that is a Docker ready version of Windows and then there's Nano Server. It's just that it's young, right? So the tooling right now, we have Docker CLI that we can use and we can, you know, build Dockerfile and build images and target either Hyper-V for on-prem or in the cloud we can do Windows container. But we don't, and we now have a swarm equivalent, but again, it's, it's evolving, right? So that's not released, but there will come a time when that now has all of the story. And the, you know, with the partnership between, I think, Microsoft, Mesosphere and Docker, I think that is what's going to start fleshing that story out very nicely. But also the service fabric is another alternative to this. Service fabric would be the, yeah, it would be the Paz way to go. That is, you know, you are accustomed to building.NET code solutions. You build a visual studio solution. And like we did with cloud services when it first came out, Azure initially had a Paz offering called cloud service before we had websites and the cloud service model is very similar to what we see only now it's much improved with lots of other things. The service fabric model, which is you have a project file, which is a first class citizen. It is an application. That application is a thing that you can deploy. It publishes to a cluster. It does it on-prem and then you publish it to your cloud cluster in the same way. And all the moving parts of the partitions and the actors and the reliable collections and all the things you built, web apps, APIs, gets deployed together and you don't need to care. Where did it go on that cluster? But you have visuals around seeing where things are. So it's very Paz in a lot of respects, right? All right. Liam Wesley has a comment here. Micro databases. Uber drivers have a micro database syncing to the data centers eventually. Model would work in microservices. In other words, keep it local until, you know, once a day or whatever you sync up. All right. So, Kali says, how do you instrument a microservice-based application? Are there any good tools? So we use the same tools as what we would for any normal application. So a lot of our logs go into Logstash and Kibana and tooling like that, which is great and everything wins in the container. So that's good. And then for metrics, we go into stats D and push it up to there. And we also have, we store a lot just in SQLite. So it's very simple. It's very clean. And then if we need to find performance information or more detailed logging, then it's just another data source that we have that we can start analyzing and pulling metrics out. But from my point of view and what we've refactored, it didn't change just because of the microservice. Sure enough. What are the nice things you can do with things like stats D, Fluent D, which is a kind of log, it grabs logs from lots of different places and then pushes them to different places. Mozilla have a brilliant thing called Heka, H-E-K-A, which does a similar thing, but has filters and Lewis scripting and so forth. But you can have a container, a Docker container that spins up and you tell it how to talk to Docker. And then it says to Docker, tell me the other containers that are running and tell me when a container gets launched and tell me when a container stops running and automatically attaches to those other containers and pulls standard out and standard error and everything. And so you don't have to worry about configuration files and all this so that you can just literally drop a copy of this container onto every single one of your hosts. And it just pulls the data from these places and then pushes it into Elasticsearch or Prometheus, Grafana, Graphite. It's amazing stuff. I mean, obviously not for the guy who doesn't want to run Linux, but he's got performance counters, so good luck to him. Mark, last time we talked last year, you told us about your deployment, continuous deployment and integration and build and everything. It sounded like the biggest Rube Goldberg thing I've ever seen in my life, but it sounded more like being on the Star Trek Enterprise bridge. And I just want to know how many tools and processes go into... estimate, how many do you have working together in concert? If it's like Star Trek at all, it's like the first contact film. I'm basically that guy who's supposed to be building warp drive but keeps getting drunk. So I've got a GitHub repository or a bunch of GitHub repositories and I push into those. That triggers a web hook which goes off to a Python flask service that's running on a T2 microservice in AWS. That pulls the Git thing and checks to see which... So I've got multiple projects. Let me just get a diagram going here. Yes, that's great. So I've got multiple microservices in a single GitHub repository because otherwise I have to pay them even more money. Bit bucket. Free. What's bit bucket? A free alternative. There isn't a lesion thing. So yeah, the Python thing pulls it down, works out which projects have changed, creates Docker containers, pushes those Docker containers to the Docker registry. I pay for 25 private repositories on the Docker registry. That then triggers another web hook which triggers a node application running on another T2 microservice. No, hang on, that's on a small Azure instance. Does it involve a fax machine? This then uses the Azure resource management SDK to spin up another VM and put all the Docker containers onto there. Then it runs a suite of automated tests against those. If those tests pass, then it sends a message to Rancher to say everything's fine and then Rancher can tell all the nodes that I've got in my entire thing. It's okay to pull a new, the latest version of this image. Once it's running on all the different nodes, that then triggers, so they update something in console. Once everything in console agrees, that triggers another thing which bounces back to Rancher again and says switch the load balance or over to the new copy of that service. So that's impressive. 53 simple steps. And not a Word document in sight. No, it's all in readme.md. It makes it much more acceptable and perfect. Except for the bits that are in my head. Yes, we do it slightly differently. I've done everything. I thought I just followed the pattern. That was great practice and stuff there. Now we just do a push, go into BitBook it because it's free. Go into Docker Hub, build it, do a Docker compose, deploy it. Simple. Four steps, how archaic. People like you are killing open source. All right. Well, I think we're just about out of time. So I'd like to give everybody a round of applause to the panel. Michelle, Mark, Ben. And we'll see you next time on.NET ROCKS! Well, OK. Thank you.
 Hey London, it's Dotnet Rocks!  Welcome to the Dachlands!  This is the end of the second day at NDC Oslo.  We do a panel discussion in front of a live studio audience.  We're generating the Super besser!  The show audience would love it!  that we have this little thing that we call better know a framework so roll the funky  music.  Alright, what did we learn?  So all the times that you've ever you know what happens that if you listen to the show  that there's this music which created by my friend here but we never hear it when we actually  record the show.  So right if you ever hear us talk about how funny that music sounds is that's live.  All lies.  It's just like filming a Star Wars against a green screen.  It's the green screen audio effect.  Exactly.  But it is kind of cool.  Alright so then you say.  And then it's also these are also edit points so if you've ever wondered why everything  sounds so smooth on a show it's because we have editors.  But you mean you're not going to keep this in?  Yeah.  I'm disappointed.  Yeah, no it's only for people who are actually in the room.  They never get to.  So you're going to excel in this show.  Yeah, an edited version of it.  So it's a Tuesday show so that's Brandon right?  Yeah.  Right this is Brandon's show.  So Brandon is the editor for this particular show.  I would say hi to Brandon.  Hi Brandon.  Hi Brandon.  We love you Brandon.  You even make us sound smart.  Which is not easy to do.  Alright so go ahead.  Okay you ready?  Alright buddy what do you got?  Well I went I you know I look for things that are trending and this is one of them.  It's called idunvis.com.  Nice.  You've done it.  You've done it.  You've done it.  Alright.  You've done hired the hit maker.  That's the reference you're making.  Yeah well idunvis is a service where you reply to an evening email reminder that you get  from it with what you did that day.  And the next day you get a digest with what everyone on the team got done.  Now I know this is like a service that really costs like five bucks a month per user but  it's not that I'm giving them a plug.  I'm saying it's not a bad idea.  I mean you know doing a sort of an email digest is something that we could probably all do  just on a Saturday while watching TV.  But so it is a pretty cool idea and I don't know if anybody else has something like this  or has written something or used something like this but I thought it was pretty compelling  so that's why I brought it up.  idunvis.com.  Love it.  Who's talking to us my friend?  Grab the comment.  Another right of point.  I grabbed your comment on the show 1125 the one we did with Seth Locker back when we were  in Nebraska talking about Docker for developers.  I think it was one of the early Docker conversations we had too because he was very much a Linux  guy.  So rather than you know he didn't have any of the issues around Windows and things with  it so we were coming at it from a Linux perspective.  But some of the comments on this were super awesome.  And the one I wanted to refer to is from, let me say it again, and Johan Obrink gave  us this great comment spot from nine months ago or so when the show first came out.  He said in the show you mentioned the lack of good tooling for managing the deployment  of Docker containers across virtual machines.  We recently started using Tutom.  That's T-U-T-U-M dot C-O.  It allows us to manage containers, private Docker hosts and cloud providers so that  containers can be provisioned across Azure, DigitalOcean, AWS and more.  By the way I've gone and taken a look at Tutom.  It's currently free under preview and it really does a lot of stuff for you in terms of just  managing containers symmetrically, no matter what platform you're working from.  The containers all perceive it as if they were on the same local network which makes  setting up redundancy really easy.  Elastic search for example will automatically distribute all indexes across all machines  without being aware of course that it could be across literally multiple cloud hosts if  you want them to be.  We can also select the best cloud for each service, DigitalOcean for disk intensive  operations as you use SSDs, AWS if you want to use data from S3 and so on while providing  fallbacks if a cloud provider could go down.  Could that ever happen?  Never.  Never.  Never.  That's just crazy.  We don't go down.  Anyway, I thought it was a great comment.  Johan thanks so much for providing that comment.  I will take a good long look at Tutom.  I hope others do as well, especially while it's in preview.  And at.NET Rocksmug is on its way to you.  If you'd like a.NET Rocksmug, write a comment on the website at.NET Rocks.com or via any  of our social media platforms.  We post every show to Google plus and Facebook and if you write a comment there, we read  it on the show.  We'll send you a mug.  And of course you can follow us on Twitter.  He's at Rich Campbell.  I'm at Carl Franklin.  What's the date on that comment?  That comment is from nine months ago.  So it was probably right after that show got published which was April of 2015.  Yeah, I just wanted to keep that in mind as we talk to the panel today and see what we  think of that.  And I guess that means we need the panel to introduce themselves.  We'll start way down at the end there.  Ben Hall, why don't you tell us everybody what you do?  Cool.  So I'm the founder of a company called Ocelot Upwall.  We're a software development studio.  So we help companies deliver training sessions on topics such as Docker.  And we also build our own internal products.  One of which is Catecoda, which is an interactive learning platform for software engineers who  can learn things like Docker in your browser without any downloads or configuration.  And Ocelot Upwall is a sophisticated code word for a pussy riot.  Okay.  Completely, completely.  For those who haven't watched our chat as we discussed this morning.  Okay, Mark.  You're up.  I'm Mark Rendell and I'm a professional podcast guest.  And you are among other things.  Didn't you say the word Docker?  I should probably say Cloud Lens, shouldn't I?  So I've been running something called Zudio, which is a terrible name.  So now I'm working on something called Cloud Lens, which is basically the next version  of that, which is ASPignet 5 and Docker and Azure and all those good things.  You have an impressive setup there that we talked about in our last show.  Yes.  So I'm still just about to actually put it live in beta.  Wow.  Awesome.  Michelle.  I'm Michelle DeRuz Monta.  I have a consulting company called Soliance.  We do a lot of migration to cloud, focus on distributed architectures.  Now microservices, previously other things.  And spending a lot of time with service fabric, Docker and I had to say Docker.  Docker Docker Docker Docker.  And I have a product called Snapboard that I'm actually also deploying to a microservice  platform.  Wow.  Wow.  Wow.  So you'd be surprised.  Why is he surprised?  I don't know.  Thank you.  Nice.  All right.  Well, who wants to go first?  I mean, first of all, any reactions to that nine month old suggestion about managing containers?  Well, yeah.  So some people it might sound surprising that Tutum is still in beta.  Once you immerse yourself in the Docker ecosystem, nine months is really not a very long time.  But no, I have, I looked at Tutum and they appear to provide a very good hosted service.  If you want someone to manage that infrastructure side of things for you.  There are open source tools that do roughly the same set of stuff, but that you have to  kind of provide the infrastructure to run the servers for that sort of thing yourself.  Right.  500 different ones.  And there are 500 different ones.  I mean, I'm for cloud lens, I'm using one called Rancher, which is very nice.  And they release, they do a new release once a week and they just broke their version numbering  because it was based on week numbers.  So now we're going back to one again.  Oh, yeah.  But no, that's a great product.  That does a similar thing.  I can run one kind of master server in the Azure North Europe data center.  And I could run it in Amazon or Digital Ocean and then I can run nodes in all the Azure  data centers, which is something that I have to do.  But as far as they're concerned, they are all a single network.  It does it, set tunneling between things.  And I can do a push to the Docker registry and 19 data centers will update themselves  with that new image.  Just automatically.  I just have that set up as a hook in Rancher to do that.  So that's what I'm using.  I'm sure that I think Ben wrote his own thing.  Probably.  Because of course he did.  And based on the container ecosystem.  Did you write it in Go?  Yeah.  A little bit.  A little bit.  That's fine.  It's proper Docker.  It's not proper Docker unless it's written in Go or maybe Python.  We didn't.  We talked to you today, Ben.  And of course the show was published weeks ago because time shifting.  And I don't know if to them was one thing that you mentioned, but no, Docker to Tom's  just been acquired by Docker said I've now bought it in house and part of the team and  Docker have to Tom.  They also have a control plane offering and which is more for on-premise and in-house  offerings.  And I think that's where they position in it.  And I think that's where they're going to be focused on the cloud.  And about very cool, but there's so much activity like Rancher, for example.  It's also a great company and a great product.  There's a huge amount to be aware of and it's hard to keep track and know what's best to  actually solve your problem.  We developed our own because we don't have the same problems as what most scalability  companies do.  And we've got.  You are a special, special flaw.  It's not a traditional website problem.  Right.  Because we're not just scaling traffic.  We're building and delivering virtual machines and environments.  And so that's why we decided to use the API directly, which it's very powerful.  It's very strong.  It's got some great wrappers.  But for most problems, I'd recommend going to some like Rancher or Kubernetes.  Or beyond.  Right.  Yeah, exactly.  A little bit depends on.  So there are companies, different companies at different stages have different problems.  So I mean, Google made Kubernetes to solve Google's problem.  And Google's problem is we need to marshal millions of CPUs and servers and get them  all to work as though they were one thing.  And we'd rather not employ 100,000 people to do that.  My problem is I would like to run as few servers as possible.  Yeah.  I would like to run my costs down.  And so Rancher works well at that.  And it sort of scales up to this level.  Kubernetes, MesaSphere, things like these schedulers are designed for when you're just  throwing huge amounts of processing power and money at getting things done as quickly  as possible and as easily as possible.  But only so far easily, right?  Because it's not really a pass.  It's still you have to manage it.  You have to throw resources at it until you get to the point where you go to a hosted  provider.  Yeah.  And that's the interesting part because I probably deal with a lot of customers that  are looking to move to microservices and not have to do all the work.  So while they're interested in some of the lower level, they're more interested in throwing  money at that problem within the services space.  And a big part of that is just because they don't have the people that know this stuff  yet.  And so it's too much of a challenge to undertake to try to think.  We can think design.  We can think microservice.  We can think building containers and distributing them.  We understand the networking.  We understand all of that stuff.  But we want somebody else to make sure it's up.  It's healthy.  It recovers.  It gives us information about the state of the whole system and so on.  So it's an interesting problem because there's so many layers.  And then when you're a developer, you just want to do stuff.  So it's kind of fun.  It's a cultural difference, I see.  And I brought this up with you, Michelle, and I also brought it up with you, Ben, today,  which is that in the Linux world, the focus is on control.  We want all the control we can get, so therefore we need to know the stack all the way up and  down.  And when something doesn't work, we can swap it out.  We like having that low-level control at the expense of the time that it takes to get up  and running.  The expertise, as Michelle was saying, versus in the Azure world, in the service fabric  world, all of that stuff is sort of just handed to you with a remote control, so to speak.  So I guess it's a difference in culture.  Well, some of it comes from, if you think about just culture and history, I remember  back in the day when I was doing mostly pre-dot-net C++ development, and then I took a hop over  to the Java space, Java, Oracle, Linux, Unix, really, and building a PaaS operation based  on that stack.  Now, I wasn't obviously managing all of the operations without help because I was new  to that space, but I was responsible for it.  And what I learned is that it's a rite of passage.  I mean, I'm not saying everybody's like that, but it does feel a lot like there's just a  raw sort of, I don't even want to say youthful approach, but it sort of feels a little bit  like that.  I just want to dig in and do stuff and get things done and figure it out.  And that sort of mantra felt very strong back in the day in the Java timeframe, in that  timeframe for me, in working with Java.  Maybe I'm just saying that because nobody wanted to help me when I went on the list.  But because when you go to the.NET space, you would see immediately there's like five,  10, 15 different magazines with people writing articles and all these resources, everyone  else is like, yeah, figure it out, dude.  Read the manual.  Call me when you're digging into the low level, I want to edit your bits that are deployed  on GitHub, and then I'll talk to you.  Mark, you have a foot in one foot in each side of this camp.  I mean, you've noticed that cultural difference, I dig it.  I'm certainly moving to, well, I'm running Linux on my actual work laptop.  Is that a self-loathing thing?  Do you know the funny thing?  You lose a bet with God.  I don't have enough.  My laptop is old dual core and eight gigs of RAM, and it really isn't up to running.  But that's a ton of power for most Linux instances.  It is, but when you're running 12 Docker containers to spin up your kind of microservice cluster  that represents your site, and you're doing that in virtual box and controlling it from  Windows, it flakes pretty quickly, whereas you do it if you've actually booted directly  into Linux, and it's using like a quarter of one CPU to do that, which is good because  it means that all the other CPUs and all the rest of the memory is there to open an extra  tab in Chrome.  So true.  Do you think that's angry or anything?  No, not at all.  But it is funny.  I know exactly what Michelle's talking about.  If you have a problem with Windows, you can go on to server fault or Stack Overflow,  and you can find the answer to that question there.  If you have a problem with Linux, then the answer will be 18 levels of greater than indentation  deep in a Piper mailing list entry from 2009, which is telling you to go and edit, slash  et cetera, slash something dot D slash something dot com.  And you're supposed to know where that is.  Yeah, you've got to find that.  Which was written by a 13-year-old brainiac, right?  Exactly.  It was written by one of the kernel maintainers, and you've got to do this on a machine that's  running in a cloud, and you've only got SSH access to it.  So you log in, and then whoever created the cloud image didn't put your editor on there,  so you're having to use nano or Pico or something to edit the file.  And you've got no idea how that works.  And you are just going, I really miss RDP at this point.  I'd like to be able to log in and get a desktop.  Is this the one with nano?  Nano's good.  It's solid, and it's easy.  Yeah, but you like breakfast burritos.  Okay, good point.  I'll give you that.  I wish I could drop this mic.  Yeah, you have to whack your head on the table.  It's right on your head.  It can probably add it in at the time of the fight later.  We could do all of those things, actually.  You could fake it, just tap the thing.  Yeah.  Well, I feel like we've spent a good 15 minutes just talking about the container set.  We're also supposed to talk about the microservice side of this whole discussion, just as a new  model of building applications.  Are they really that different from good old SOA?  Yeah.  No?  It's the same stuff.  WCF from microservices.  It's an evolution of that mantra.  It's an evolution of those principles, but done in a way that sort of evolves to additional  principles.  I like to look at it like everybody hates buzzwords.  You hear microservice and you want to kill yourself now because it's everywhere.  Or multi-family.  Right.  Or a number of people.  I wouldn't include you in that.  It's okay.  But you hear it all the time, but what really is important is really the underlying change  in how people will approach building systems, and you might argue that it's forcing people  to do things better because it forces you to think about upfront, why don't we actually  think about the domain?  Why don't we actually break up the services so it's manageable to deploy and update?  It makes so much logical sense that you cannot deploy monolithic things.  We used to think of monolithic things as a single executable, but I see websites with  maybe five, six, seven different API endpoints, but each of those has so many assemblies and  so many crossing waves of shared code, and then the database is just this one monolith.  It's literally impossible to update that.  It's literally fearful to update that.  It makes a lot of sense to change how we think.  How far you go micro is completely dependent on the kind of thing you're building and where  you want to get to, but the principles are solid and it helps you to think that through.  Do you remember five years ago, our friend, Javall Loe.  Every class is a service.  Every class should be a service.  This was his mantra, Javall Loe.  No, it's true.  Was he right?  He said that before microservices, the term was, I think, really wrong.  I brought this up with Ben today, which is it's not that the class is the boundary.  It's what it's doing, the domain job.  Right.  Well, then it's not a class.  Every service is not a microservice, but every microservice is a service.  You still have to think in domains.  There might be a single thing that is just a cache, Redis, and that's a service with  data.  Then there may be a single thing that is just an identity server with data.  That single identity server might have three APIs, three services within the construct  of that holistic feature area.  But you really want everything to do with identity in that server.  All that is updated together.  All that is a unit of thinking as a team to, can we deploy this and not affect the rest  of all of our products that depend on it, that kind of thing.  You have to get out of the thought of every service equals microservice, every API equals  a microservice, because that's too granular for a lot of things.  You still have crossing database relations that need to be somehow collected under maybe  several APIs, but grouped together and hopefully safely separated from others like it.  We're going to do questions from the audience, a little different tweet at Carl Franklin.  I will read your questions because we don't have an audience microphone.  Sorry about that.  That's what we call an edit point.  I wrote a blog post about a series of blog posts because I made my new years resolution  that I was going to write a blog post every day.  So I wrote three blog posts.  That's ambitious.  No matter what.  It lasted three days.  It lasted much longer than my diary.  I'm going to open a gym called Resolutions and for the first two weeks it's going to  be a gym and then it's going to turn into a bar for the rest of the year.  I'll sign for that.  But no, I wrote a post saying do one thing and do it well, which was born out of frustration  with the Azure Storage SDK, which has got so complicated over the years and talks to Key  Vault and talks to all these different things.  I was just kind of like why don't you break it out because all I want to do is upload  a blog.  Right.  So get the bit that does blogs and release it as your blog SDK and as your whatever.  And I don't mind if each of those SDKs has a dependency on a core package, but you could  fix the bug in the blog SDK without us having to wait for Key Vault to release a.NET core  version of that.  Anyway.  And then I sort of took this a step further and said microservices and I said do one thing  with microservices.  And I gave an example from my project where I actually use a microservice to do JWT verification.  So JSON web tokens.  JSON web token, you've got three parts.  The first bit is a base64 encoded metadata about the token.  And then in the middle, you've got a base64 encoded JSON string, which is all your claims.  And then the last bit is a hash created using a private key of that middle bit so that you  can't change the token.  So the token has to, you know, it's been issued by your authenticated server.  And you can write libraries for this and all this other stuff, but I've got, you know,  multiple containers running on the same machine.  And so my ASPnet5 authentication process just bounces that as a string across to this microservice,  which has got two endpoints.  And it's got verify.  And if it's okay, then it gives you back the JSON of the claims, which you can then put  into your claims principle.  And if it's not, it bounces back a 403 saying that's not right.  And I'm sure that someone in the audience, hello, will tell me the 403 is the wrong status  code for that.  And the thing is, people were going, that, you know, that is, it's a class and it's  a method call on a class to verify a JSON web token.  Why would you do that?  Why would you split that out into a microservice?  That's just stupid.  And so I had to write another blog post to prove how clever I am.  Where I said, okay, at the moment, I've got an X509 certificate that I'm using to verify  this thing.  And that gets into the microservice in this way.  But I might decide to change that and use Azure Key Vault and pass the thing across to  there because that has an API, which you can pass a string and it sends you back an adapter.  So it is, it's essentially, it's a replaceable, instead of doing dependency injection, I can  do use a different container with a different service inside it with the same API.  And I can switch around.  If I've got some services running in Azure and I want to use Azure Key Vault, and I've  got some services running in AWS and I want to use their Key Vault or I want to use Hashicore's  Vault tool, which is extremely good as well, I can, I can switch these things out without  having to recompile every single service just because I've changed the way I'm doing  JWT, generation and authentication.  That's a perfect example of why you should be decomposing things in the microservice.  But it raises something interesting, which is the security issues around going microservices  beyond the obvious stuff that people worry about with multi-tenancy and, you know, container  segregation and networking and so on, isolation.  But it actually comes back to, if you think about services, boundaries as something that  always must be authenticated and authorized in some way, and if you adopt the modern topology  for identity and authorization, which would be token based across all the tiers, then  now we have possibly more hops than we used to if we're doing composition that goes deep  that needs to be authorized, that now need token validation.  Where's Dominic?  Is Dominic here?  I know.  No?  No.  No.  He's probably doing it, Tom.  But, but, but see, this is the issue though, is that, you know, there's overhead with that.  It's not too much in a traditional environment where you maybe only have two hops for the  round trip from top down.  But the question is how much is too much?  I don't know that we can answer that question right now.  I mean, I think that perhaps the methodologies around how we protect things that are, you  know, behind a network might have to change.  But token based is how we deal with it today because we're standardizing on APIs, which  have traditionally less hops before you get back to the, to the front.  We start breaking things out smaller and have more hops and more token validations.  Now we're going to have to start benchmarking what's the right approach.  Is it okay to say, well, this is in a private network and there's zero chance, but, but  see the security person in me says no, you can't ever say that this might not be exposed.  And if you don't protect it at the software level, then somebody exposes it and now you're  screwed.  So not okay.  So there's, there's a lot to think about there, right?  It's a design issue and it's a performance potentially, you know, you know, you know,  performance based concern.  Yeah.  But it could evolve to maybe different types of validation, perhaps maybe it's not going  to be asymmetric, maybe it's got to be symmetric and we go back to H Mac or something like  that, just something.  So, but yeah, I mean, the example of hello, can you verify this token for me?  And yes, I've done that.  So obviously you want to do that over IP sec tunneling.  And you want to do the token server can't be on any kind of public IP address.  It has to be on an internal only IP address.  But yes, as soon as you get into things where you've got a big fabric of 32 hosts and messages  are bouncing around all over it.  So that's now hitting the real network rather than just an internal Docker bridge.  Then yeah, you've got another set of issues.  So at which point I would say, okay, so now we need to solve that problem as well.  Yeah.  But if I ever get to the point where I'm running 32 servers in every data center, I'll just  pay someone to solve that problem.  Yeah, I'll find somebody smarter.  Yes.  Good one.  I'll pay Troy to come and sort out.  Nice.  Hey Richard.  Yeah, buddy.  I'm going to be that happy time.  It's time to announce that I have no joke today.  Well, everybody's very excited about that.  Oh man, rough, rough crap.  It's actually time to give away a component one studio to one lucky member of the dotnet  rocks fan club.  First, let me tell you about Grape City active reports.  The first product we ever advertised on dotnet.  That's a long time ago.  This is the reporting platform for all your business needs, design, publish, view, print,  and export operational reports such as invoices, expense reports, tax and government forms,  as well as strategic and analytical reports such as sales performance, budgeting and  revenue analysis.  Active reports gives you the operation and flexibility you need to turn your data into  informative pixel perfect reports across the enterprise.  Nice.  So who's our winner?  The winner is George Britton.  Congratulations George.  Good to meet you.  You get a real clap.  Not just a golf clap.  Real clap for you, sir.  Yes, indeed.  And George just won the component one.  Excuse me.  That's why we have editors.  For all about.  Because of your wind.  Yes, because of my gas.  And George just won the component one studio from component one in Grape City.  And if you don't know what we're doing here, go to.NETROX.COM, click on the big get free  stuff button, answer a few questions and join the.NETROX fan club.  We have thousands of members all over the world and army of members in fact.  And every show we like to give away stuff from our sponsors and every December we give  away a $5,000 technology shopping spree to one lucky member of the.NETROX fan club.  But you've got to sign up to win.  We've done it four times already.  Yeah.  And we also like to ask our guests, guys, if you had $5,000 to spend on technology  today, what would you buy?  Michelle.  Oh, come on.  She just did this earlier today.  I just did this earlier today.  I know.  Make us something else.  I got to think about it.  New toys.  New toys.  More toys.  There's so many.  So many toys.  I want a recording studio.  Do you really?  Wow.  In my office.  Okay, go to soundsuckers.com.  Okay.  And you can get a four by six isolation booth for five grand.  Perfect.  There you go.  Oh my God.  I hit the five grand for a change.  You did?  Well done.  I'm normally way under.  When do I pick it up?  Mark.  Hello, Lens developer kit and Adele Precision 5000.  That was easy.  Yeah, boom.  That's over five grand, actually.  Yeah.  Depending on how you configure the Adele Precision.  If I don't pay Adele for the extra memory and I go and buy it from Crucial, then I keep  it down under the two.  Yeah, at least then it's homework.  So yeah.  But yeah, maybe the whole Lens Dev kit.  3000 bucks, US risk like that.  That's if they feel like giving it to you.  Have you tried to fill in the form for the HoloLens Dev kit?  No.  They ask very specific questions.  Yeah, like are you in the US or Canada?  Oh.  That's it.  They begin there, but they're very keen on you have apps in the wild built in Unity.  That's sort of their barrier to entry.  I downloaded Unity.  Does that count?  How always counts.  I've got a book.  I play Kerbal Space Program.  That's Unity.  I've got a book.  I've read it.  I tried putting it under my pillow to see if I absorbed the knowledge.  See, we go straight through.  I made the little bar go around the screen.  I have a game I want to write.  Not for HoloLens.  I want to do the HoloLens thing where you draw in your route on a map and then put your  HoloLens on and go out for a run and it puts coins along your route.  You just run along and every time you run past a coin it goes, there's a problem with  that.  It doesn't work outside.  I know, but yeah.  Sorry.  It's just version one.  The future version.  I know.  Fine.  Yeah.  I'm going to put it in your hands, hun.  I wish I did because I'm not going to actually do this stuff.  Ben, what would you buy with five grand?  So I was looking at Seb's new massive iPad and that looked pretty cool.  Hold that thing up, Seb.  Oh, is that the iPad?  Holy crap.  That's the giant iPad.  Yeah.  The iPad that thinks it's a surface.  Wow.  Pretty much.  It comes with its own $500 pen.  If you see that in the shop next to the iPad Air, it is two iPad Airs stuck together.  Wow.  It is literally twice as much.  Wow.  Gigantic.  It's huge.  And it's running iOS, which is just a complete waste of all that processing.  Well, I appreciate Apple equipment is expensive, but I don't think that's five grand.  Oh, it's when you had a HoloLens.  All right.  We got some questions from the audience.  This is from Ollie.  How would you fix the performance outliers in microservices, which are a standard problem?  What?  Performance outliers.  Ollie, I think that requires a little explanation.  Raise your hand.  There it is.  Go ahead.  Oh, no, not you.  Basically, you see, Microsoft says, well, when you have the Microsoft service, you have  to be able to do that.  So that's an availability problem, not really performance.  Okay.  Anybody who wants to answer that, just repeat the question, please.  Are you talking about the number of hops per se?  Like in terms of distributing densely across the nodes, that's, I mean, additional availability.  So what are you referring to?  Introducing more opportunities for partition.  Partitioning.  And for a service to go down.  Therefore, all the other services that depend.  See, I really want to give the position some so that if you take a service that's three  nine, can you just repeat the question for us?  The question was, if you've got a service that's three nines and you break that down  into two services.  Three nines.  Nine.  99.9% uptime.  Uptime.  Yeah, uptime.  Yeah, uptime.  Yeah, availability.  And you split that into two services.  Then have you introduced, you know, do you now have?  Have you now doubled the risk of downtime?  A 99.8.  Yeah.  Or have you got six nines?  Yeah.  Which, no, you haven't got six nines.  If you split that into 15, have you got an infinite number of nines?  So if you need that kind of uptime availability, then obviously you have at least three instances  of each service.  And this is what schedulers like Kubernetes and MesaSphere and Fleet are for.  It's really, really just kind of maniacal, pathological monitoring to say, I need at  least this many instances of this service running.  And then the other thing that you need to work out is how the communication between those  services happens.  Because you can do microservices that talk HTTP to each other.  You can do microservices that talk native TCP protocols like Protobuf and whatever.  And you can do microservices that talk over a distributed bus like ZeroMQ or Kafka.  And at that point, you know, you just have to hope Kafka doesn't go down because if Kafka  goes down, then you're down for days.  But yeah, you know, this is really more of a philosophical argument about how reliability  works.  Yes.  And probability as well.  Well, I mean, that's an element of it.  You can play that math game if you want.  Probability is not cumulative.  Right?  Yeah.  You have a 50-50 chance of flipping heads or tails every time you flip.  Yeah.  It doesn't matter how many times.  Flip ten heads in a row.  Right.  You still have 50-50 chance of heads the eleventh time.  Right.  But you still have to deal with the same issues we talked about earlier, which is I don't care  if it's a microservice or an API today.  You have to, you know, build resiliency into your application.  You have to have retries and back off retries at every single node that you call.  And redundant.  And you have to have redundancy.  Use poly.  And fail over capabilities in place.  And, you know, this is how we should already and I think aspire to design systems today  without microservices.  When you have microservices, you're just more acutely aware, I think, of this fragility.  Yeah.  But then this is where you get into the philosophical element.  You have to build one monolithic thing that never goes down no matter what, where you build  a whole bunch of things that when they go down, you don't care.  Yeah.  Because the service isn't actually down.  The analogy that's just popped into my head is if you've got an aircraft carrier and it  gets a hold in it, then the whole thing sinks probably.  Right.  And everybody drowns.  Whereas if you've got 50,000 rowing boats and one of them gets a hold in it, then one  rowing boat goes down and probably the people who were in it can climb into one of the other  rowing boats.  Yeah, but you should see the gun on those rowing boats.  Oh, man.  Particularly if you build those rowing boats from six inch thick steel.  Yeah.  You got off the aircraft here you took part.  Yeah, so yes, you introduced the possibility there are more things that could disappear,  but at the same time, each of those things has fewer moving parts.  Okay.  And we'll move on to another.  Fewer vulnerabilities.  We'll move on to the next question.  It's from Tom.  How do databases work well with microservices?  Microdatabases?  Nice.  Yeah, why not?  If you're breaking down your application, like we were talking earlier on about the fact  that what was a bounded context has now become a microservice.  If you can separate your business model and your logic out into those things and create  those boundaries, then why would you want to ruin that all by putting all the data in  the same Oracle database?  Right.  And you give yourself the possibility to go, right.  The financial data obviously needs to be in an asset compliant transactional database  replicated across multiple nodes and backed up every night.  So, you know, as you're a SQL database or Oracle, if you hate yourself and like deploying  DBAs.  So true though.  You're never sponsored by Oracle, are you?  Yeah.  Not anymore anyway.  Yeah.  There's the Oracle licensing model.  How much money have you got?  And for the privilege of updates, we will take X a year, right?  Yes.  And if you have no money, you can have MySQL, which will teach you to have no money.  Postgres people.  Come on.  But yes, you can kind of go, right, so this goes into this.  With microservices, one of the awesome things about microservices is you can go, you know  what, there's a really nice node library for doing that.  There's a really nice go library for doing that.  And a brilliant Python library for doing this kind of machine learning sort of thing.  Yeah.  And so you use the right tool for the right part of your service.  And it's the same with your data.  You can have, you know, some stuff needs to go in a SQL database.  Some stuff can go in a document database.  Some stuff can go in a Y value column store, like table storage or the central.  And paraphrasing from Ben from your show earlier.  You do want to let stuff to be stored outside of the container in something a little more  durable than any given container.  And when I put my IT hat on, that doesn't preclude reliability, backup, like all of those things.  Just because you have stuff stored in different locations in different ways doesn't mean it  isn't still valuable to the organization and needs care and feeding.  It doesn't have to be a DBA.  It just has to be somebody who knows what files.  Yeah.  Or the last guy standing next to the database when the last guy left.  You.  You're it.  I think the other model that is introduced though is the partitioning model.  For example, I like what service fabric is doing around partitioning.  The idea of partition early because they'll handle it.  So, you know, you think A to Z or you think, you know, one through 100 partitions based  on whatever it is, country, states, you know, last names, whatever the case may be.  You break it up as far as you can up front and then you let them handle saying, oh, well,  you only need two servers.  So we'll just distribute across the two or three in the cluster.  But now when it's time to, you know, spread out, you've already done the job.  And in the meantime, they have a naming service that can go ahead and do the queries and find  the right partition.  So it's done right up front.  And that's the right way to do partitioning.  It's just that it forces us to think too early about that.  But when you start thinking in micro, you can start thinking in micro around that as well.  And now it becomes a little bit more manageable.  Everything becomes manageable.  The part that feels nerve wracking is the potential of the chaos monkey in the middle  because there's so many moving parts now.  So now we do the better job around the moving parts.  I also want to talk.  I find that relatively few people think about partitioning chronologically.  Like as a guy who built a lot of e-commerce sites, like keeping more than the last seven days  of data in the very fast data store is dumb.  Right?  Like it's just no reason.  The data is not going to change.  It's journal.  I'll call you from there.  Yeah.  Get it out of there.  Get it out of there often.  It can't be one day because there are reconciliations.  But it only needs to be a few days.  And if you just get into this habit right at the beginning of we have a rolling window of  time and then when the arbitrary definition of a month ends, then we pull that off and  do things with it.  But the vast majority of that data never, ever, ever, ever changes.  Put it in a read-only state and it'll turn out it performs awesome when nobody's allowed to modify it.  All right.  We only have a few minutes, so I really want to get to some of these other questions here.  Is there a Windows, and this is from Ian, is there a Windows story on microservices for those of us who  have avoided Linux thus far and quite like it that way?  Michelle, I think that's your, your, your house.  Well, there, there is a in-progress version of that.  So we have a Windows Server 2016 Tech Preview 3.  Save that fast five times.  I dare you.  And that is a Docker ready version of Windows and then there's Nano Server.  It's just that it's young, right?  So the tooling right now, we have Docker CLI that we can use and we can, you know, build Dockerfile  and build images and target either Hyper-V for on-prem or in the cloud we can do Windows container.  But we don't, and we now have a swarm equivalent, but again, it's, it's evolving, right?  So that's not released, but there will come a time when that now has all of the story.  And the, you know, with the partnership between, I think, Microsoft, Mesosphere and Docker,  I think that is what's going to start fleshing that story out very nicely.  But also the service fabric is another alternative to this.  Service fabric would be the, yeah, it would be the Paz way to go.  That is, you know, you are accustomed to building.NET code solutions.  You build a visual studio solution.  And like we did with cloud services when it first came out, Azure initially had a Paz offering called cloud service  before we had websites and the cloud service model is very similar to what we see only now it's much improved  with lots of other things.  The service fabric model, which is you have a project file, which is a first class citizen.  It is an application.  That application is a thing that you can deploy.  It publishes to a cluster.  It does it on-prem and then you publish it to your cloud cluster in the same way.  And all the moving parts of the partitions and the actors and the reliable collections and all the things you built,  web apps, APIs, gets deployed together and you don't need to care.  Where did it go on that cluster?  But you have visuals around seeing where things are.  So it's very Paz in a lot of respects, right?  All right.  Liam Wesley has a comment here.  Micro databases.  Uber drivers have a micro database syncing to the data centers eventually.  Model would work in microservices.  In other words, keep it local until, you know, once a day or whatever you sync up.  All right.  So, Kali says, how do you instrument a microservice-based application?  Are there any good tools?  So we use the same tools as what we would for any normal application.  So a lot of our logs go into Logstash and Kibana and tooling like that,  which is great and everything wins in the container.  So that's good.  And then for metrics, we go into stats D and push it up to there.  And we also have, we store a lot just in SQLite.  So it's very simple.  It's very clean.  And then if we need to find performance information or more detailed logging,  then it's just another data source that we have that we can start analyzing and pulling metrics out.  But from my point of view and what we've refactored, it didn't change just because of the microservice.  Sure enough.  What are the nice things you can do with things like stats D, Fluent D,  which is a kind of log, it grabs logs from lots of different places  and then pushes them to different places.  Mozilla have a brilliant thing called Heka, H-E-K-A,  which does a similar thing, but has filters and Lewis scripting and so forth.  But you can have a container, a Docker container that spins up  and you tell it how to talk to Docker.  And then it says to Docker, tell me the other containers that are running  and tell me when a container gets launched and tell me when a container stops running  and automatically attaches to those other containers and pulls standard out  and standard error and everything.  And so you don't have to worry about configuration files and all this  so that you can just literally drop a copy of this container onto every single one of your hosts.  And it just pulls the data from these places and then pushes it into Elasticsearch  or Prometheus, Grafana, Graphite.  It's amazing stuff.  I mean, obviously not for the guy who doesn't want to run Linux,  but he's got performance counters, so good luck to him.  Mark, last time we talked last year, you told us about your deployment,  continuous deployment and integration and build and everything.  It sounded like the biggest Rube Goldberg thing I've ever seen in my life,  but it sounded more like being on the Star Trek Enterprise bridge.  And I just want to know how many tools and processes go into...  estimate, how many do you have working together in concert?  If it's like Star Trek at all, it's like the first contact film.  I'm basically that guy who's supposed to be building warp drive but keeps getting drunk.  So I've got a GitHub repository or a bunch of GitHub repositories  and I push into those.  That triggers a web hook which goes off to a Python flask service  that's running on a T2 microservice in AWS.  That pulls the Git thing and checks to see which...  So I've got multiple projects.  Let me just get a diagram going here.  Yes, that's great.  So I've got multiple microservices in a single GitHub repository  because otherwise I have to pay them even more money.  Bit bucket.  Free.  What's bit bucket?  A free alternative.  There isn't a lesion thing.  So yeah, the Python thing pulls it down,  works out which projects have changed, creates Docker containers,  pushes those Docker containers to the Docker registry.  I pay for 25 private repositories on the Docker registry.  That then triggers another web hook which triggers a node application  running on another T2 microservice.  No, hang on, that's on a small Azure instance.  Does it involve a fax machine?  This then uses the Azure resource management SDK  to spin up another VM and put all the Docker containers onto there.  Then it runs a suite of automated tests against those.  If those tests pass, then it sends a message to Rancher  to say everything's fine and then Rancher can tell all the nodes  that I've got in my entire thing.  It's okay to pull a new, the latest version of this image.  Once it's running on all the different nodes,  that then triggers, so they update something in console.  Once everything in console agrees, that triggers another thing  which bounces back to Rancher again and says switch the load balance  or over to the new copy of that service.  So that's impressive.  53 simple steps.  And not a Word document in sight.  No, it's all in readme.md.  It makes it much more acceptable and perfect.  Except for the bits that are in my head.  Yes, we do it slightly differently.  I've done everything.  I thought I just followed the pattern.  That was great practice and stuff there.  Now we just do a push, go into BitBook it because it's free.  Go into Docker Hub, build it, do a Docker compose, deploy it.  Simple.  Four steps, how archaic.  People like you are killing open source.  All right.  Well, I think we're just about out of time.  So I'd like to give everybody a round of applause to the panel.  Michelle, Mark, Ben.  And we'll see you next time on.NET ROCKS!  Well, OK.  Thank you.
NET_Rocks_Live_____Containers___Microservices_Panel_HD_0_635.png NET_Rocks_Live_____Containers___Microservices_Panel_HD_636_1859.png NET_Rocks_Live_____Containers___Microservices_Panel_HD_1860_1907.png NET_Rocks_Live_____Containers___Microservices_Panel_HD_1908_2315.png NET_Rocks_Live_____Containers___Microservices_Panel_HD_2316_3695.png NET_Rocks_Live_____Containers___Microservices_Panel_HD_3696_5843.png NET_Rocks_Live_____Containers___Microservices_Panel_HD_5844_9035.png NET_Rocks_Live_____Containers___Microservices_Panel_HD_9036_18215.png NET_Rocks_Live_____Containers___Microservices_Panel_HD_18216_18611.png NET_Rocks_Live_____Containers___Microservices_Panel_HD_18612_23399.png NET_Rocks_Live_____Containers___Microservices_Panel_HD_23400_31379.png NET_Rocks_Live_____Containers___Microservices_Panel_HD_31380_64895.png NET_Rocks_Live_____Containers___Microservices_Panel_HD_64896_66839.png NET_Rocks_Live_____Containers___Microservices_Panel_HD_66840_82236.png
Hey London, it's Dotnet Rocks! Welcome to the Dachlands! This is the end of the second day at NDC Oslo. We do a panel discussion in front of a live studio audience. We're generating the Super besser! The show audience would love it! that we have this little thing that we call better know a framework so roll the funky music. Alright, what did we learn? So all the times that you've ever you know what happens that if you listen to the show that there's this music which created by my friend here but we never hear it when we actually record the show. So right if you ever hear us talk about how funny that music sounds is that's live. All lies. It's just like filming a Star Wars against a green screen. It's the green screen audio effect. Exactly. But it is kind of cool. Alright so then you say. And then it's also these are also edit points so if you've ever wondered why everything sounds so smooth on a show it's because we have editors. But you mean you're not going to keep this in? Yeah. I'm disappointed. Yeah, no it's only for people who are actually in the room. They never get to. So you're going to excel in this show. Yeah, an edited version of it. So it's a Tuesday show so that's Brandon right? Yeah. Right this is Brandon's show. So Brandon is the editor for this particular show. I would say hi to Brandon. Hi Brandon. Hi Brandon. We love you Brandon. You even make us sound smart. Which is not easy to do. Alright so go ahead. Okay you ready? Alright buddy what do you got? Well I went I you know I look for things that are trending and this is one of them. It's called idunvis.com. Nice. You've done it. You've done it. You've done it. Alright. You've done hired the hit maker. That's the reference you're making. Yeah well idunvis is a service where you reply to an evening email reminder that you get from it with what you did that day. And the next day you get a digest with what everyone on the team got done. Now I know this is like a service that really costs like five bucks a month per user but it's not that I'm giving them a plug. I'm saying it's not a bad idea. I mean you know doing a sort of an email digest is something that we could probably all do just on a Saturday while watching TV. But so it is a pretty cool idea and I don't know if anybody else has something like this or has written something or used something like this but I thought it was pretty compelling so that's why I brought it up. idunvis.com. Love it. Who's talking to us my friend? Grab the comment. Another right of point. I grabbed your comment on the show 1125 the one we did with Seth Locker back when we were in Nebraska talking about Docker for developers. I think it was one of the early Docker conversations we had too because he was very much a Linux guy. So rather than you know he didn't have any of the issues around Windows and things with it so we were coming at it from a Linux perspective. But some of the comments on this were super awesome. And the one I wanted to refer to is from, let me say it again, and Johan Obrink gave us this great comment spot from nine months ago or so when the show first came out. He said in the show you mentioned the lack of good tooling for managing the deployment of Docker containers across virtual machines. We recently started using Tutom. That's T-U-T-U-M dot C-O. It allows us to manage containers, private Docker hosts and cloud providers so that containers can be provisioned across Azure, DigitalOcean, AWS and more. By the way I've gone and taken a look at Tutom. It's currently free under preview and it really does a lot of stuff for you in terms of just managing containers symmetrically, no matter what platform you're working from. The containers all perceive it as if they were on the same local network which makes setting up redundancy really easy. Elastic search for example will automatically distribute all indexes across all machines without being aware of course that it could be across literally multiple cloud hosts if you want them to be. We can also select the best cloud for each service, DigitalOcean for disk intensive operations as you use SSDs, AWS if you want to use data from S3 and so on while providing fallbacks if a cloud provider could go down. Could that ever happen? Never. Never. Never. That's just crazy. We don't go down. Anyway, I thought it was a great comment. Johan thanks so much for providing that comment. I will take a good long look at Tutom. I hope others do as well, especially while it's in preview. And at.NET Rocksmug is on its way to you. If you'd like a.NET Rocksmug, write a comment on the website at.NET Rocks.com or via any of our social media platforms. We post every show to Google plus and Facebook and if you write a comment there, we read it on the show. We'll send you a mug. And of course you can follow us on Twitter. He's at Rich Campbell. I'm at Carl Franklin. What's the date on that comment? That comment is from nine months ago. So it was probably right after that show got published which was April of 2015. Yeah, I just wanted to keep that in mind as we talk to the panel today and see what we think of that. And I guess that means we need the panel to introduce themselves. We'll start way down at the end there. Ben Hall, why don't you tell us everybody what you do? Cool. So I'm the founder of a company called Ocelot Upwall. We're a software development studio. So we help companies deliver training sessions on topics such as Docker. And we also build our own internal products. One of which is Catecoda, which is an interactive learning platform for software engineers who can learn things like Docker in your browser without any downloads or configuration. And Ocelot Upwall is a sophisticated code word for a pussy riot. Okay. Completely, completely. For those who haven't watched our chat as we discussed this morning. Okay, Mark. You're up. I'm Mark Rendell and I'm a professional podcast guest. And you are among other things. Didn't you say the word Docker? I should probably say Cloud Lens, shouldn't I? So I've been running something called Zudio, which is a terrible name. So now I'm working on something called Cloud Lens, which is basically the next version of that, which is ASPignet 5 and Docker and Azure and all those good things. You have an impressive setup there that we talked about in our last show. Yes. So I'm still just about to actually put it live in beta. Wow. Awesome. Michelle. I'm Michelle DeRuz Monta. I have a consulting company called Soliance. We do a lot of migration to cloud, focus on distributed architectures. Now microservices, previously other things. And spending a lot of time with service fabric, Docker and I had to say Docker. Docker Docker Docker Docker. And I have a product called Snapboard that I'm actually also deploying to a microservice platform. Wow. Wow. Wow. So you'd be surprised. Why is he surprised? I don't know. Thank you. Nice. All right. Well, who wants to go first? I mean, first of all, any reactions to that nine month old suggestion about managing containers? Well, yeah. So some people it might sound surprising that Tutum is still in beta. Once you immerse yourself in the Docker ecosystem, nine months is really not a very long time. But no, I have, I looked at Tutum and they appear to provide a very good hosted service. If you want someone to manage that infrastructure side of things for you. There are open source tools that do roughly the same set of stuff, but that you have to kind of provide the infrastructure to run the servers for that sort of thing yourself. Right. 500 different ones. And there are 500 different ones. I mean, I'm for cloud lens, I'm using one called Rancher, which is very nice. And they release, they do a new release once a week and they just broke their version numbering because it was based on week numbers. So now we're going back to one again. Oh, yeah. But no, that's a great product. That does a similar thing. I can run one kind of master server in the Azure North Europe data center. And I could run it in Amazon or Digital Ocean and then I can run nodes in all the Azure data centers, which is something that I have to do. But as far as they're concerned, they are all a single network. It does it, set tunneling between things. And I can do a push to the Docker registry and 19 data centers will update themselves with that new image. Just automatically. I just have that set up as a hook in Rancher to do that. So that's what I'm using. I'm sure that I think Ben wrote his own thing. Probably. Because of course he did. And based on the container ecosystem. Did you write it in Go? Yeah. A little bit. A little bit. That's fine. It's proper Docker. It's not proper Docker unless it's written in Go or maybe Python. We didn't. We talked to you today, Ben. And of course the show was published weeks ago because time shifting. And I don't know if to them was one thing that you mentioned, but no, Docker to Tom's just been acquired by Docker said I've now bought it in house and part of the team and Docker have to Tom. They also have a control plane offering and which is more for on-premise and in-house offerings. And I think that's where they position in it. And I think that's where they're going to be focused on the cloud. And about very cool, but there's so much activity like Rancher, for example. It's also a great company and a great product. There's a huge amount to be aware of and it's hard to keep track and know what's best to actually solve your problem. We developed our own because we don't have the same problems as what most scalability companies do. And we've got. You are a special, special flaw. It's not a traditional website problem. Right. Because we're not just scaling traffic. We're building and delivering virtual machines and environments. And so that's why we decided to use the API directly, which it's very powerful. It's very strong. It's got some great wrappers. But for most problems, I'd recommend going to some like Rancher or Kubernetes. Or beyond. Right. Yeah, exactly. A little bit depends on. So there are companies, different companies at different stages have different problems. So I mean, Google made Kubernetes to solve Google's problem. And Google's problem is we need to marshal millions of CPUs and servers and get them all to work as though they were one thing. And we'd rather not employ 100,000 people to do that. My problem is I would like to run as few servers as possible. Yeah. I would like to run my costs down. And so Rancher works well at that. And it sort of scales up to this level. Kubernetes, MesaSphere, things like these schedulers are designed for when you're just throwing huge amounts of processing power and money at getting things done as quickly as possible and as easily as possible. But only so far easily, right? Because it's not really a pass. It's still you have to manage it. You have to throw resources at it until you get to the point where you go to a hosted provider. Yeah. And that's the interesting part because I probably deal with a lot of customers that are looking to move to microservices and not have to do all the work. So while they're interested in some of the lower level, they're more interested in throwing money at that problem within the services space. And a big part of that is just because they don't have the people that know this stuff yet. And so it's too much of a challenge to undertake to try to think. We can think design. We can think microservice. We can think building containers and distributing them. We understand the networking. We understand all of that stuff. But we want somebody else to make sure it's up. It's healthy. It recovers. It gives us information about the state of the whole system and so on. So it's an interesting problem because there's so many layers. And then when you're a developer, you just want to do stuff. So it's kind of fun. It's a cultural difference, I see. And I brought this up with you, Michelle, and I also brought it up with you, Ben, today, which is that in the Linux world, the focus is on control. We want all the control we can get, so therefore we need to know the stack all the way up and down. And when something doesn't work, we can swap it out. We like having that low-level control at the expense of the time that it takes to get up and running. The expertise, as Michelle was saying, versus in the Azure world, in the service fabric world, all of that stuff is sort of just handed to you with a remote control, so to speak. So I guess it's a difference in culture. Well, some of it comes from, if you think about just culture and history, I remember back in the day when I was doing mostly pre-dot-net C++ development, and then I took a hop over to the Java space, Java, Oracle, Linux, Unix, really, and building a PaaS operation based on that stack. Now, I wasn't obviously managing all of the operations without help because I was new to that space, but I was responsible for it. And what I learned is that it's a rite of passage. I mean, I'm not saying everybody's like that, but it does feel a lot like there's just a raw sort of, I don't even want to say youthful approach, but it sort of feels a little bit like that. I just want to dig in and do stuff and get things done and figure it out. And that sort of mantra felt very strong back in the day in the Java timeframe, in that timeframe for me, in working with Java. Maybe I'm just saying that because nobody wanted to help me when I went on the list. But because when you go to the.NET space, you would see immediately there's like five, 10, 15 different magazines with people writing articles and all these resources, everyone else is like, yeah, figure it out, dude. Read the manual. Call me when you're digging into the low level, I want to edit your bits that are deployed on GitHub, and then I'll talk to you. Mark, you have a foot in one foot in each side of this camp. I mean, you've noticed that cultural difference, I dig it. I'm certainly moving to, well, I'm running Linux on my actual work laptop. Is that a self-loathing thing? Do you know the funny thing? You lose a bet with God. I don't have enough. My laptop is old dual core and eight gigs of RAM, and it really isn't up to running. But that's a ton of power for most Linux instances. It is, but when you're running 12 Docker containers to spin up your kind of microservice cluster that represents your site, and you're doing that in virtual box and controlling it from Windows, it flakes pretty quickly, whereas you do it if you've actually booted directly into Linux, and it's using like a quarter of one CPU to do that, which is good because it means that all the other CPUs and all the rest of the memory is there to open an extra tab in Chrome. So true. Do you think that's angry or anything? No, not at all. But it is funny. I know exactly what Michelle's talking about. If you have a problem with Windows, you can go on to server fault or Stack Overflow, and you can find the answer to that question there. If you have a problem with Linux, then the answer will be 18 levels of greater than indentation deep in a Piper mailing list entry from 2009, which is telling you to go and edit, slash et cetera, slash something dot D slash something dot com. And you're supposed to know where that is. Yeah, you've got to find that. Which was written by a 13-year-old brainiac, right? Exactly. It was written by one of the kernel maintainers, and you've got to do this on a machine that's running in a cloud, and you've only got SSH access to it. So you log in, and then whoever created the cloud image didn't put your editor on there, so you're having to use nano or Pico or something to edit the file. And you've got no idea how that works. And you are just going, I really miss RDP at this point. I'd like to be able to log in and get a desktop. Is this the one with nano? Nano's good. It's solid, and it's easy. Yeah, but you like breakfast burritos. Okay, good point. I'll give you that. I wish I could drop this mic. Yeah, you have to whack your head on the table. It's right on your head. It can probably add it in at the time of the fight later. We could do all of those things, actually. You could fake it, just tap the thing. Yeah. Well, I feel like we've spent a good 15 minutes just talking about the container set. We're also supposed to talk about the microservice side of this whole discussion, just as a new model of building applications. Are they really that different from good old SOA? Yeah. No? It's the same stuff. WCF from microservices. It's an evolution of that mantra. It's an evolution of those principles, but done in a way that sort of evolves to additional principles. I like to look at it like everybody hates buzzwords. You hear microservice and you want to kill yourself now because it's everywhere. Or multi-family. Right. Or a number of people. I wouldn't include you in that. It's okay. But you hear it all the time, but what really is important is really the underlying change in how people will approach building systems, and you might argue that it's forcing people to do things better because it forces you to think about upfront, why don't we actually think about the domain? Why don't we actually break up the services so it's manageable to deploy and update? It makes so much logical sense that you cannot deploy monolithic things. We used to think of monolithic things as a single executable, but I see websites with maybe five, six, seven different API endpoints, but each of those has so many assemblies and so many crossing waves of shared code, and then the database is just this one monolith. It's literally impossible to update that. It's literally fearful to update that. It makes a lot of sense to change how we think. How far you go micro is completely dependent on the kind of thing you're building and where you want to get to, but the principles are solid and it helps you to think that through. Do you remember five years ago, our friend, Javall Loe. Every class is a service. Every class should be a service. This was his mantra, Javall Loe. No, it's true. Was he right? He said that before microservices, the term was, I think, really wrong. I brought this up with Ben today, which is it's not that the class is the boundary. It's what it's doing, the domain job. Right. Well, then it's not a class. Every service is not a microservice, but every microservice is a service. You still have to think in domains. There might be a single thing that is just a cache, Redis, and that's a service with data. Then there may be a single thing that is just an identity server with data. That single identity server might have three APIs, three services within the construct of that holistic feature area. But you really want everything to do with identity in that server. All that is updated together. All that is a unit of thinking as a team to, can we deploy this and not affect the rest of all of our products that depend on it, that kind of thing. You have to get out of the thought of every service equals microservice, every API equals a microservice, because that's too granular for a lot of things. You still have crossing database relations that need to be somehow collected under maybe several APIs, but grouped together and hopefully safely separated from others like it. We're going to do questions from the audience, a little different tweet at Carl Franklin. I will read your questions because we don't have an audience microphone. Sorry about that. That's what we call an edit point. I wrote a blog post about a series of blog posts because I made my new years resolution that I was going to write a blog post every day. So I wrote three blog posts. That's ambitious. No matter what. It lasted three days. It lasted much longer than my diary. I'm going to open a gym called Resolutions and for the first two weeks it's going to be a gym and then it's going to turn into a bar for the rest of the year. I'll sign for that. But no, I wrote a post saying do one thing and do it well, which was born out of frustration with the Azure Storage SDK, which has got so complicated over the years and talks to Key Vault and talks to all these different things. I was just kind of like why don't you break it out because all I want to do is upload a blog. Right. So get the bit that does blogs and release it as your blog SDK and as your whatever. And I don't mind if each of those SDKs has a dependency on a core package, but you could fix the bug in the blog SDK without us having to wait for Key Vault to release a.NET core version of that. Anyway. And then I sort of took this a step further and said microservices and I said do one thing with microservices. And I gave an example from my project where I actually use a microservice to do JWT verification. So JSON web tokens. JSON web token, you've got three parts. The first bit is a base64 encoded metadata about the token. And then in the middle, you've got a base64 encoded JSON string, which is all your claims. And then the last bit is a hash created using a private key of that middle bit so that you can't change the token. So the token has to, you know, it's been issued by your authenticated server. And you can write libraries for this and all this other stuff, but I've got, you know, multiple containers running on the same machine. And so my ASPnet5 authentication process just bounces that as a string across to this microservice, which has got two endpoints. And it's got verify. And if it's okay, then it gives you back the JSON of the claims, which you can then put into your claims principle. And if it's not, it bounces back a 403 saying that's not right. And I'm sure that someone in the audience, hello, will tell me the 403 is the wrong status code for that. And the thing is, people were going, that, you know, that is, it's a class and it's a method call on a class to verify a JSON web token. Why would you do that? Why would you split that out into a microservice? That's just stupid. And so I had to write another blog post to prove how clever I am. Where I said, okay, at the moment, I've got an X509 certificate that I'm using to verify this thing. And that gets into the microservice in this way. But I might decide to change that and use Azure Key Vault and pass the thing across to there because that has an API, which you can pass a string and it sends you back an adapter. So it is, it's essentially, it's a replaceable, instead of doing dependency injection, I can do use a different container with a different service inside it with the same API. And I can switch around. If I've got some services running in Azure and I want to use Azure Key Vault, and I've got some services running in AWS and I want to use their Key Vault or I want to use Hashicore's Vault tool, which is extremely good as well, I can, I can switch these things out without having to recompile every single service just because I've changed the way I'm doing JWT, generation and authentication. That's a perfect example of why you should be decomposing things in the microservice. But it raises something interesting, which is the security issues around going microservices beyond the obvious stuff that people worry about with multi-tenancy and, you know, container segregation and networking and so on, isolation. But it actually comes back to, if you think about services, boundaries as something that always must be authenticated and authorized in some way, and if you adopt the modern topology for identity and authorization, which would be token based across all the tiers, then now we have possibly more hops than we used to if we're doing composition that goes deep that needs to be authorized, that now need token validation. Where's Dominic? Is Dominic here? I know. No? No. No. He's probably doing it, Tom. But, but, but see, this is the issue though, is that, you know, there's overhead with that. It's not too much in a traditional environment where you maybe only have two hops for the round trip from top down. But the question is how much is too much? I don't know that we can answer that question right now. I mean, I think that perhaps the methodologies around how we protect things that are, you know, behind a network might have to change. But token based is how we deal with it today because we're standardizing on APIs, which have traditionally less hops before you get back to the, to the front. We start breaking things out smaller and have more hops and more token validations. Now we're going to have to start benchmarking what's the right approach. Is it okay to say, well, this is in a private network and there's zero chance, but, but see the security person in me says no, you can't ever say that this might not be exposed. And if you don't protect it at the software level, then somebody exposes it and now you're screwed. So not okay. So there's, there's a lot to think about there, right? It's a design issue and it's a performance potentially, you know, you know, you know, performance based concern. Yeah. But it could evolve to maybe different types of validation, perhaps maybe it's not going to be asymmetric, maybe it's got to be symmetric and we go back to H Mac or something like that, just something. So, but yeah, I mean, the example of hello, can you verify this token for me? And yes, I've done that. So obviously you want to do that over IP sec tunneling. And you want to do the token server can't be on any kind of public IP address. It has to be on an internal only IP address. But yes, as soon as you get into things where you've got a big fabric of 32 hosts and messages are bouncing around all over it. So that's now hitting the real network rather than just an internal Docker bridge. Then yeah, you've got another set of issues. So at which point I would say, okay, so now we need to solve that problem as well. Yeah. But if I ever get to the point where I'm running 32 servers in every data center, I'll just pay someone to solve that problem. Yeah, I'll find somebody smarter. Yes. Good one. I'll pay Troy to come and sort out. Nice. Hey Richard. Yeah, buddy. I'm going to be that happy time. It's time to announce that I have no joke today. Well, everybody's very excited about that. Oh man, rough, rough crap. It's actually time to give away a component one studio to one lucky member of the dotnet rocks fan club. First, let me tell you about Grape City active reports. The first product we ever advertised on dotnet. That's a long time ago. This is the reporting platform for all your business needs, design, publish, view, print, and export operational reports such as invoices, expense reports, tax and government forms, as well as strategic and analytical reports such as sales performance, budgeting and revenue analysis. Active reports gives you the operation and flexibility you need to turn your data into informative pixel perfect reports across the enterprise. Nice. So who's our winner? The winner is George Britton. Congratulations George. Good to meet you. You get a real clap. Not just a golf clap. Real clap for you, sir. Yes, indeed. And George just won the component one. Excuse me. That's why we have editors. For all about. Because of your wind. Yes, because of my gas. And George just won the component one studio from component one in Grape City. And if you don't know what we're doing here, go to.NETROX.COM, click on the big get free stuff button, answer a few questions and join the.NETROX fan club. We have thousands of members all over the world and army of members in fact. And every show we like to give away stuff from our sponsors and every December we give away a $5,000 technology shopping spree to one lucky member of the.NETROX fan club. But you've got to sign up to win. We've done it four times already. Yeah. And we also like to ask our guests, guys, if you had $5,000 to spend on technology today, what would you buy? Michelle. Oh, come on. She just did this earlier today. I just did this earlier today. I know. Make us something else. I got to think about it. New toys. New toys. More toys. There's so many. So many toys. I want a recording studio. Do you really? Wow. In my office. Okay, go to soundsuckers.com. Okay. And you can get a four by six isolation booth for five grand. Perfect. There you go. Oh my God. I hit the five grand for a change. You did? Well done. I'm normally way under. When do I pick it up? Mark. Hello, Lens developer kit and Adele Precision 5000. That was easy. Yeah, boom. That's over five grand, actually. Yeah. Depending on how you configure the Adele Precision. If I don't pay Adele for the extra memory and I go and buy it from Crucial, then I keep it down under the two. Yeah, at least then it's homework. So yeah. But yeah, maybe the whole Lens Dev kit. 3000 bucks, US risk like that. That's if they feel like giving it to you. Have you tried to fill in the form for the HoloLens Dev kit? No. They ask very specific questions. Yeah, like are you in the US or Canada? Oh. That's it. They begin there, but they're very keen on you have apps in the wild built in Unity. That's sort of their barrier to entry. I downloaded Unity. Does that count? How always counts. I've got a book. I play Kerbal Space Program. That's Unity. I've got a book. I've read it. I tried putting it under my pillow to see if I absorbed the knowledge. See, we go straight through. I made the little bar go around the screen. I have a game I want to write. Not for HoloLens. I want to do the HoloLens thing where you draw in your route on a map and then put your HoloLens on and go out for a run and it puts coins along your route. You just run along and every time you run past a coin it goes, there's a problem with that. It doesn't work outside. I know, but yeah. Sorry. It's just version one. The future version. I know. Fine. Yeah. I'm going to put it in your hands, hun. I wish I did because I'm not going to actually do this stuff. Ben, what would you buy with five grand? So I was looking at Seb's new massive iPad and that looked pretty cool. Hold that thing up, Seb. Oh, is that the iPad? Holy crap. That's the giant iPad. Yeah. The iPad that thinks it's a surface. Wow. Pretty much. It comes with its own $500 pen. If you see that in the shop next to the iPad Air, it is two iPad Airs stuck together. Wow. It is literally twice as much. Wow. Gigantic. It's huge. And it's running iOS, which is just a complete waste of all that processing. Well, I appreciate Apple equipment is expensive, but I don't think that's five grand. Oh, it's when you had a HoloLens. All right. We got some questions from the audience. This is from Ollie. How would you fix the performance outliers in microservices, which are a standard problem? What? Performance outliers. Ollie, I think that requires a little explanation. Raise your hand. There it is. Go ahead. Oh, no, not you. Basically, you see, Microsoft says, well, when you have the Microsoft service, you have to be able to do that. So that's an availability problem, not really performance. Okay. Anybody who wants to answer that, just repeat the question, please. Are you talking about the number of hops per se? Like in terms of distributing densely across the nodes, that's, I mean, additional availability. So what are you referring to? Introducing more opportunities for partition. Partitioning. And for a service to go down. Therefore, all the other services that depend. See, I really want to give the position some so that if you take a service that's three nine, can you just repeat the question for us? The question was, if you've got a service that's three nines and you break that down into two services. Three nines. Nine. 99.9% uptime. Uptime. Yeah, uptime. Yeah, uptime. Yeah, availability. And you split that into two services. Then have you introduced, you know, do you now have? Have you now doubled the risk of downtime? A 99.8. Yeah. Or have you got six nines? Yeah. Which, no, you haven't got six nines. If you split that into 15, have you got an infinite number of nines? So if you need that kind of uptime availability, then obviously you have at least three instances of each service. And this is what schedulers like Kubernetes and MesaSphere and Fleet are for. It's really, really just kind of maniacal, pathological monitoring to say, I need at least this many instances of this service running. And then the other thing that you need to work out is how the communication between those services happens. Because you can do microservices that talk HTTP to each other. You can do microservices that talk native TCP protocols like Protobuf and whatever. And you can do microservices that talk over a distributed bus like ZeroMQ or Kafka. And at that point, you know, you just have to hope Kafka doesn't go down because if Kafka goes down, then you're down for days. But yeah, you know, this is really more of a philosophical argument about how reliability works. Yes. And probability as well. Well, I mean, that's an element of it. You can play that math game if you want. Probability is not cumulative. Right? Yeah. You have a 50-50 chance of flipping heads or tails every time you flip. Yeah. It doesn't matter how many times. Flip ten heads in a row. Right. You still have 50-50 chance of heads the eleventh time. Right. But you still have to deal with the same issues we talked about earlier, which is I don't care if it's a microservice or an API today. You have to, you know, build resiliency into your application. You have to have retries and back off retries at every single node that you call. And redundant. And you have to have redundancy. Use poly. And fail over capabilities in place. And, you know, this is how we should already and I think aspire to design systems today without microservices. When you have microservices, you're just more acutely aware, I think, of this fragility. Yeah. But then this is where you get into the philosophical element. You have to build one monolithic thing that never goes down no matter what, where you build a whole bunch of things that when they go down, you don't care. Yeah. Because the service isn't actually down. The analogy that's just popped into my head is if you've got an aircraft carrier and it gets a hold in it, then the whole thing sinks probably. Right. And everybody drowns. Whereas if you've got 50,000 rowing boats and one of them gets a hold in it, then one rowing boat goes down and probably the people who were in it can climb into one of the other rowing boats. Yeah, but you should see the gun on those rowing boats. Oh, man. Particularly if you build those rowing boats from six inch thick steel. Yeah. You got off the aircraft here you took part. Yeah, so yes, you introduced the possibility there are more things that could disappear, but at the same time, each of those things has fewer moving parts. Okay. And we'll move on to another. Fewer vulnerabilities. We'll move on to the next question. It's from Tom. How do databases work well with microservices? Microdatabases? Nice. Yeah, why not? If you're breaking down your application, like we were talking earlier on about the fact that what was a bounded context has now become a microservice. If you can separate your business model and your logic out into those things and create those boundaries, then why would you want to ruin that all by putting all the data in the same Oracle database? Right. And you give yourself the possibility to go, right. The financial data obviously needs to be in an asset compliant transactional database replicated across multiple nodes and backed up every night. So, you know, as you're a SQL database or Oracle, if you hate yourself and like deploying DBAs. So true though. You're never sponsored by Oracle, are you? Yeah. Not anymore anyway. Yeah. There's the Oracle licensing model. How much money have you got? And for the privilege of updates, we will take X a year, right? Yes. And if you have no money, you can have MySQL, which will teach you to have no money. Postgres people. Come on. But yes, you can kind of go, right, so this goes into this. With microservices, one of the awesome things about microservices is you can go, you know what, there's a really nice node library for doing that. There's a really nice go library for doing that. And a brilliant Python library for doing this kind of machine learning sort of thing. Yeah. And so you use the right tool for the right part of your service. And it's the same with your data. You can have, you know, some stuff needs to go in a SQL database. Some stuff can go in a document database. Some stuff can go in a Y value column store, like table storage or the central. And paraphrasing from Ben from your show earlier. You do want to let stuff to be stored outside of the container in something a little more durable than any given container. And when I put my IT hat on, that doesn't preclude reliability, backup, like all of those things. Just because you have stuff stored in different locations in different ways doesn't mean it isn't still valuable to the organization and needs care and feeding. It doesn't have to be a DBA. It just has to be somebody who knows what files. Yeah. Or the last guy standing next to the database when the last guy left. You. You're it. I think the other model that is introduced though is the partitioning model. For example, I like what service fabric is doing around partitioning. The idea of partition early because they'll handle it. So, you know, you think A to Z or you think, you know, one through 100 partitions based on whatever it is, country, states, you know, last names, whatever the case may be. You break it up as far as you can up front and then you let them handle saying, oh, well, you only need two servers. So we'll just distribute across the two or three in the cluster. But now when it's time to, you know, spread out, you've already done the job. And in the meantime, they have a naming service that can go ahead and do the queries and find the right partition. So it's done right up front. And that's the right way to do partitioning. It's just that it forces us to think too early about that. But when you start thinking in micro, you can start thinking in micro around that as well. And now it becomes a little bit more manageable. Everything becomes manageable. The part that feels nerve wracking is the potential of the chaos monkey in the middle because there's so many moving parts now. So now we do the better job around the moving parts. I also want to talk. I find that relatively few people think about partitioning chronologically. Like as a guy who built a lot of e-commerce sites, like keeping more than the last seven days of data in the very fast data store is dumb. Right? Like it's just no reason. The data is not going to change. It's journal. I'll call you from there. Yeah. Get it out of there. Get it out of there often. It can't be one day because there are reconciliations. But it only needs to be a few days. And if you just get into this habit right at the beginning of we have a rolling window of time and then when the arbitrary definition of a month ends, then we pull that off and do things with it. But the vast majority of that data never, ever, ever, ever changes. Put it in a read-only state and it'll turn out it performs awesome when nobody's allowed to modify it. All right. We only have a few minutes, so I really want to get to some of these other questions here. Is there a Windows, and this is from Ian, is there a Windows story on microservices for those of us who have avoided Linux thus far and quite like it that way? Michelle, I think that's your, your, your house. Well, there, there is a in-progress version of that. So we have a Windows Server 2016 Tech Preview 3. Save that fast five times. I dare you. And that is a Docker ready version of Windows and then there's Nano Server. It's just that it's young, right? So the tooling right now, we have Docker CLI that we can use and we can, you know, build Dockerfile and build images and target either Hyper-V for on-prem or in the cloud we can do Windows container. But we don't, and we now have a swarm equivalent, but again, it's, it's evolving, right? So that's not released, but there will come a time when that now has all of the story. And the, you know, with the partnership between, I think, Microsoft, Mesosphere and Docker, I think that is what's going to start fleshing that story out very nicely. But also the service fabric is another alternative to this. Service fabric would be the, yeah, it would be the Paz way to go. That is, you know, you are accustomed to building.NET code solutions. You build a visual studio solution. And like we did with cloud services when it first came out, Azure initially had a Paz offering called cloud service before we had websites and the cloud service model is very similar to what we see only now it's much improved with lots of other things. The service fabric model, which is you have a project file, which is a first class citizen. It is an application. That application is a thing that you can deploy. It publishes to a cluster. It does it on-prem and then you publish it to your cloud cluster in the same way. And all the moving parts of the partitions and the actors and the reliable collections and all the things you built, web apps, APIs, gets deployed together and you don't need to care. Where did it go on that cluster? But you have visuals around seeing where things are. So it's very Paz in a lot of respects, right? All right. Liam Wesley has a comment here. Micro databases. Uber drivers have a micro database syncing to the data centers eventually. Model would work in microservices. In other words, keep it local until, you know, once a day or whatever you sync up. All right. So, Kali says, how do you instrument a microservice-based application? Are there any good tools? So we use the same tools as what we would for any normal application. So a lot of our logs go into Logstash and Kibana and tooling like that, which is great and everything wins in the container. So that's good. And then for metrics, we go into stats D and push it up to there. And we also have, we store a lot just in SQLite. So it's very simple. It's very clean. And then if we need to find performance information or more detailed logging, then it's just another data source that we have that we can start analyzing and pulling metrics out. But from my point of view and what we've refactored, it didn't change just because of the microservice. Sure enough. What are the nice things you can do with things like stats D, Fluent D, which is a kind of log, it grabs logs from lots of different places and then pushes them to different places. Mozilla have a brilliant thing called Heka, H-E-K-A, which does a similar thing, but has filters and Lewis scripting and so forth. But you can have a container, a Docker container that spins up and you tell it how to talk to Docker. And then it says to Docker, tell me the other containers that are running and tell me when a container gets launched and tell me when a container stops running and automatically attaches to those other containers and pulls standard out and standard error and everything. And so you don't have to worry about configuration files and all this so that you can just literally drop a copy of this container onto every single one of your hosts. And it just pulls the data from these places and then pushes it into Elasticsearch or Prometheus, Grafana, Graphite. It's amazing stuff. I mean, obviously not for the guy who doesn't want to run Linux, but he's got performance counters, so good luck to him. Mark, last time we talked last year, you told us about your deployment, continuous deployment and integration and build and everything. It sounded like the biggest Rube Goldberg thing I've ever seen in my life, but it sounded more like being on the Star Trek Enterprise bridge. And I just want to know how many tools and processes go into... estimate, how many do you have working together in concert? If it's like Star Trek at all, it's like the first contact film. I'm basically that guy who's supposed to be building warp drive but keeps getting drunk. So I've got a GitHub repository or a bunch of GitHub repositories and I push into those. That triggers a web hook which goes off to a Python flask service that's running on a T2 microservice in AWS. That pulls the Git thing and checks to see which... So I've got multiple projects. Let me just get a diagram going here. Yes, that's great. So I've got multiple microservices in a single GitHub repository because otherwise I have to pay them even more money. Bit bucket. Free. What's bit bucket? A free alternative. There isn't a lesion thing. So yeah, the Python thing pulls it down, works out which projects have changed, creates Docker containers, pushes those Docker containers to the Docker registry. I pay for 25 private repositories on the Docker registry. That then triggers another web hook which triggers a node application running on another T2 microservice. No, hang on, that's on a small Azure instance. Does it involve a fax machine? This then uses the Azure resource management SDK to spin up another VM and put all the Docker containers onto there. Then it runs a suite of automated tests against those. If those tests pass, then it sends a message to Rancher to say everything's fine and then Rancher can tell all the nodes that I've got in my entire thing. It's okay to pull a new, the latest version of this image. Once it's running on all the different nodes, that then triggers, so they update something in console. Once everything in console agrees, that triggers another thing which bounces back to Rancher again and says switch the load balance or over to the new copy of that service. So that's impressive. 53 simple steps. And not a Word document in sight. No, it's all in readme.md. It makes it much more acceptable and perfect. Except for the bits that are in my head. Yes, we do it slightly differently. I've done everything. I thought I just followed the pattern. That was great practice and stuff there. Now we just do a push, go into BitBook it because it's free. Go into Docker Hub, build it, do a Docker compose, deploy it. Simple. Four steps, how archaic. People like you are killing open source. All right. Well, I think we're just about out of time. So I'd like to give everybody a round of applause to the panel. Michelle, Mark, Ben. And we'll see you next time on.NET ROCKS! Well, OK. Thank you.
it from a Linux perspective. But some of the the end there. Ben Hall, why don't you tell us do. But as far as they're concerned, they are all house and part of the team and Docker have to be focused on the cloud. And about very cool, but desktop. Is this the one with nano? Nano's good. Carl Franklin. I will read your questions because project where I actually use a microservice to do different container with a different service do microservices that talk HTTP to each other. What are the nice things you can do with things containers and pulls standard out and standard