1 00:00:00,000 --> 00:00:21,480 Well, this past weekend was July 4th, which for those of us, or not us, for those people who are not here in the States, as they probably call it, that's the celebration of Independence Day, where we broke away from the tyrant of King George or something like that, which I guess is sort of topical for King George's legacy, breaking away from the tyranny of the EU. 2 00:00:21,680 --> 00:00:36,760 I guess that happened as well. I've been reading, I don't know about you, Richard, but I've been reading all these, like how the Brexit affects IT. And as far as I can tell, man, the reporters have to come up with, they got to really scrape the bottom of the bucket to come up with stuff. 3 00:00:37,480 --> 00:00:59,580 There's been a lot of, I think, link-baity headlines that put that Brexit in there, which I think is probably one of the best SEO terms has ever come up. It's very specific. It doesn't exist before this. So there's a lot of stories being written. It sounds like maybe it's harder to recruit people, and then maybe some sort of policies. Something's happening. I don't know. Have you concluded anything? 4 00:01:00,380 --> 00:01:11,460 No, I think you're right. I think it's a lot of concern, but at the same time, you know, one for a reason. And like you say, it's a fantastic term. Pivotal has clearly missed a chance to have, you know, how PCF saves you from Brexit. 5 00:01:11,880 --> 00:01:12,180 Oh, yeah. 6 00:01:12,240 --> 00:01:14,000 And, you know, we have not taken advantage of the SEO. 7 00:01:14,380 --> 00:01:24,960 Yeah, that's true. Or how our big data solutions will help deal with your Brexit data sovereignty problems or something. I don't think either of those are true, but man, what a great post that would be. 8 00:01:25,800 --> 00:01:30,680 Well, this week we have another guest on. You want to introduce yourself briefly, guest? 9 00:01:30,980 --> 00:01:32,560 Yeah, Kevin Hoffman. 10 00:01:33,340 --> 00:01:41,620 Well, fantastic. Well, as usual, what we'll do is we'll go over a little, a slight bit of news items that we have, and you can feel free to join in or not, Kevin. 11 00:01:41,760 --> 00:01:45,100 It depends how much of, you know, how much you want to talk about on that stuff. 12 00:01:45,220 --> 00:01:51,940 And then we'll get a more detailed introduction of who you are and talk about what's going on with you and things you've been working on recently. 13 00:01:53,560 --> 00:01:59,280 So with that, it's – I think, you know, while we published weekly, it's been a couple weeks since we recorded. 14 00:01:59,960 --> 00:02:04,060 And I think that one of the larger – we've got a couple of things to go over here. 15 00:02:04,120 --> 00:02:11,200 One, there's been a couple surveys that have come out, one of which, surprisingly, I haven't read that much, given how much I use its predecessors. 16 00:02:11,700 --> 00:02:13,700 And then also there was DockerCon. 17 00:02:13,840 --> 00:02:17,180 There was a good overview of their – in InfoQ. 18 00:02:17,600 --> 00:02:23,440 There's quite a bit of announcements that they had there, which is an interesting thing to track in the container world. 19 00:02:23,520 --> 00:02:32,640 I think looking over the news story, you know, a lot of why people like containers is driven by developers finding them easier and things like that. 20 00:02:32,640 --> 00:02:43,920 And the Docker CEO had an interesting stat that 25% of the attendees were – had something associated with being a sysadmin, which sort of confirms that to some extent. 21 00:02:44,020 --> 00:02:49,860 I'm sure there were like 10 or 15% who were like vendors and other sort of like hanger-oners, if you will. 22 00:02:50,400 --> 00:02:59,680 But it sounds like the majority of people there were developers at the conference, which, you know, conference attendee stats are never like, I don't know, scientific. 23 00:03:00,240 --> 00:03:05,200 But they are interesting wet fingers in the wind to kind of just figure out the direction things are going. 24 00:03:05,260 --> 00:03:09,660 It's kind of like going outside of your house and looking at the color of clouds and figuring out if it's going to rain or not. 25 00:03:10,120 --> 00:03:10,900 It's something. 26 00:03:11,340 --> 00:03:12,700 Better than just staring at the wall. 27 00:03:13,640 --> 00:03:13,980 That's right. 28 00:03:14,020 --> 00:03:15,100 A little bit of early predictor. 29 00:03:15,460 --> 00:03:15,720 Yeah. 30 00:03:15,840 --> 00:03:16,160 A little help. 31 00:03:16,620 --> 00:03:23,420 And I saw – I mean basically like a lot of the other people in this space, they're essentially focusing a lot on orchestration. 32 00:03:23,580 --> 00:03:32,660 That is managing big as, you know, I guess pun intended, big swarms of containers that they have and adding more of a platform nature to that, to their stuff. 33 00:03:34,060 --> 00:03:34,460 Yeah. 34 00:03:34,660 --> 00:03:38,100 I mean, as you mentioned, InfoQ did a nice write-up there. 35 00:03:38,400 --> 00:03:43,400 I guess we should also plug the Coté article on InfoQ that's also been well-received on cloud and portability. 36 00:03:43,400 --> 00:03:45,000 But you're welcome, Coté. 37 00:03:45,180 --> 00:03:49,220 But yeah, the DockerCon stuff, it was good stuff. 38 00:03:49,300 --> 00:03:50,140 It was up here in Seattle. 39 00:03:50,460 --> 00:03:53,080 So it was the same time as our cloud-native roadshow up here. 40 00:03:53,160 --> 00:03:56,080 So you had a lot of techies descending on the Seattle area. 41 00:03:56,580 --> 00:03:59,280 And as you mentioned, there was some big stuff with the orchestration. 42 00:03:59,440 --> 00:04:06,340 What was fascinating, though, is, you know, some of the flash, you know, hot takes where, oh, this really spells some trouble for Kubernetes now. 43 00:04:06,400 --> 00:04:11,640 Because now the company that is containers, if you will, is embedding orchestration into their product. 44 00:04:11,720 --> 00:04:12,820 Why would I go use something else? 45 00:04:13,300 --> 00:04:20,400 But like any hot takes, you know, you take a deep breath and say, you know what, what the really key thing is that there is no winner yet. 46 00:04:20,940 --> 00:04:26,540 And so there's still just a lot of things shaking out as people figure out what does it mean to run and operate these things at scale. 47 00:04:26,620 --> 00:04:29,840 Anybody who thinks they've picked a winner yet is remarkably premature. 48 00:04:29,840 --> 00:04:38,280 Sure, to some extent, I think that's why we like talking about platforms, because you want to abstract away some of that plumbing that will absolutely change over the next few years. 49 00:04:38,640 --> 00:04:40,080 There's absolutely guarantee it. 50 00:04:40,280 --> 00:04:42,640 So interesting to see some of the hand-wringing. 51 00:04:42,740 --> 00:04:50,620 I think anybody who thinks it was already over, that, hey, Kubernetes won or Mesos is winning or Swarm, like, just use the right thing that makes sense for you right now. 52 00:04:50,680 --> 00:04:53,000 Just don't be married to it, because odds are things will change. 53 00:04:53,000 --> 00:04:59,940 But other good stuff coming out of the conference, again, good tooling, some interesting stuff around security scanning. 54 00:05:00,200 --> 00:05:03,200 I think they finally shipped the betas for the Mac and Windows Docker tooling. 55 00:05:03,460 --> 00:05:04,700 So all good stuff. 56 00:05:04,780 --> 00:05:09,180 These conferences seem to be a good place for not just news, but then some nice technical hands-on stuff. 57 00:05:09,320 --> 00:05:14,740 And the more people that talk about microservices and containers and operational efficiency, the better. 58 00:05:15,560 --> 00:05:21,880 Yeah, I mean, speaking of hot takes, which begs the question, where's the cold takes or, you know, I don't know, lukewarm ones? 59 00:05:21,880 --> 00:05:27,500 Room temperature, like a pack of defrosted hot dogs being all July 4th themed. 60 00:05:28,100 --> 00:05:34,500 But, yeah, over on my other podcast, Software Defined Talk, we talked a lot about the DockerCon stuff. 61 00:05:34,740 --> 00:05:39,600 And, you know, we have two other people on there, one person who works at Chef and another who works at IBM. 62 00:05:40,040 --> 00:05:46,140 And the guy, Matt Ray, on there, he's always good at explaining what's going on in this container orchestration area. 63 00:05:46,300 --> 00:05:50,720 So there's I think the last three episodes actually has been me playing like dumb person. 64 00:05:50,920 --> 00:05:56,760 And as I am on this topic and basically just asking him to explain the layout and what's going on and everything. 65 00:05:56,760 --> 00:05:59,040 So there's there's some more in-depth conversation there. 66 00:05:59,580 --> 00:06:08,300 But I think I think to your point, one of the surveys that that I was mentioning earlier is the Cloud Foundry Foundation, which is hosted at the Linux Foundation. 67 00:06:08,300 --> 00:06:11,740 And they're the people who are the the stewards of cloud, the Cloud Foundry code. 68 00:06:11,840 --> 00:06:15,120 And I guess, you know, the other ephemera around it. 69 00:06:15,180 --> 00:06:16,180 They came out with a survey. 70 00:06:16,340 --> 00:06:18,520 This is released like a week and a half ago or so. 71 00:06:18,720 --> 00:06:19,160 I forget. 72 00:06:19,460 --> 00:06:19,660 Right. 73 00:06:19,920 --> 00:06:20,780 But recently. 74 00:06:21,160 --> 00:06:21,320 Yeah. 75 00:06:21,340 --> 00:06:23,580 And I forget the name of the company they worked with. 76 00:06:23,600 --> 00:06:31,940 But as you do with these survey things, they worked with some company and surveyed 711 or 711, just like the convenience store people. 77 00:06:31,940 --> 00:06:35,940 And if you look at the demographics, I think it's pretty interesting because it's spread across. 78 00:06:36,440 --> 00:06:40,240 It's basically bucketed out in thirds across company size. 79 00:06:40,300 --> 00:06:49,020 And if I remember, to some extent, geographies, so it's it's I think I think it's a good another good representative thing of how people are using containers and what they're doing. 80 00:06:49,020 --> 00:07:03,360 And as you would expect from the Cloud Foundry Foundation, what's different about their container survey from other people is they put the the idea of platform as a service and platform in there as well, not just container orchestration and containers on their own. 81 00:07:03,460 --> 00:07:08,480 And then I think as a result, you see that that that widening of the aperture. 82 00:07:08,480 --> 00:07:12,600 I think that means making something bigger and not a big photography person. 83 00:07:12,880 --> 00:07:18,340 But you see you see more things considered in the full scope of how you're managing. 84 00:07:18,460 --> 00:07:22,480 People are managing infrastructure and using containers and all sorts of things like that. 85 00:07:23,840 --> 00:07:29,420 Yeah, I mean, these things can always be a tad self-serving, but I like that we're trying to think of me. 86 00:07:29,500 --> 00:07:30,640 It's fun to talk containers. 87 00:07:30,820 --> 00:07:32,540 It's fun to cover all these things in orchestration. 88 00:07:32,620 --> 00:07:35,960 We have to remember that this is still plumbing and this is stuff that's very complicated. 89 00:07:35,960 --> 00:07:40,360 We could try to simplify it with nice UX or, you know, simpler manifest. 90 00:07:40,620 --> 00:07:43,340 But, you know, figuring out the right way to do these things is not trivial. 91 00:07:43,540 --> 00:07:46,380 It's multi-page guides to get some of these things stood up right. 92 00:07:46,460 --> 00:07:47,940 So fun to see the surveys. 93 00:07:48,080 --> 00:07:50,360 Good to see people looking in this space. 94 00:07:50,940 --> 00:07:54,860 And I guess, as always, it's stay tuned to see where this thing stuff or where this stuff goes. 95 00:07:55,240 --> 00:08:03,540 Yeah, and I would, I would, there's a few questions and charts in there and we'll put links to all this stuff in the show notes, of course, that I thought were kind of interesting. 96 00:08:03,640 --> 00:08:15,060 One of them, this is a fun trick survey people do a lot, is they chunk out people who are evaluating versus using some technology and see how they answer the questions differently. 97 00:08:15,140 --> 00:08:31,780 Like, I don't know if it's famously, but famously in my canon of surveys, this is the exciting life I live, usually if you ask people, and this is several years back, about what are the problems with cloud, just in general, using cloud. 98 00:08:31,980 --> 00:08:37,480 And people who hadn't used cloud yet or were evaluating it would always say security was a big deal. 99 00:08:37,720 --> 00:08:43,820 And then you would look at the bucket of people who had been using cloud for some time and security, like, fell way down the list. 100 00:08:43,960 --> 00:08:58,540 I mean, maybe not way down, but it fell down to the middle of the list, which, if you look at that, you know, at least the way I interpret it is people are, perhaps rightly so, but they're misinformed in a paranoid way about the challenges they'll have with cloud. 101 00:08:58,540 --> 00:09:02,240 Or putting it another way, they worry about different things until they use it. 102 00:09:02,840 --> 00:09:11,520 So, similarly, in this survey, there's one question that basically buckets out people who are evaluating containers versus using containers. 103 00:09:12,060 --> 00:09:18,300 And it's not quite the same as the cloud security one, but, in fact, it's kind of the opposite. 104 00:09:18,600 --> 00:09:25,140 It's the concerns about managing containers go up when you actually use them versus when you're just evaluating them. 105 00:09:25,140 --> 00:09:29,580 So, it ends up being more complicated than people had anticipated, it seems. 106 00:09:30,040 --> 00:09:30,720 Yeah, isn't that true? 107 00:09:30,880 --> 00:09:32,900 That's a good segue into the second survey. 108 00:09:33,080 --> 00:09:36,740 So, the 2016 DevOps report came out. 109 00:09:36,840 --> 00:09:42,360 And I think this is maybe, you might know since it's fresher in your head, this is maybe the sixth or seventh one that they've done. 110 00:09:43,120 --> 00:09:47,600 And I think they started doing this at Puppet Labs however many years ago. 111 00:09:47,800 --> 00:09:51,600 And it's actually expanded to have all sorts of other people who back it and use it. 112 00:09:52,120 --> 00:10:03,980 And they, I think maybe about three years ago, if I remember, they added Nicole to it, who's actually like has a background in stats and surveys and stuff. 113 00:10:04,100 --> 00:10:09,660 So, as she will joke when you see presentations, there's a lot more science in it than there was. 114 00:10:09,720 --> 00:10:11,120 And there's some slight revisions. 115 00:10:11,420 --> 00:10:13,880 So, it's actually, I think, a pretty good report. 116 00:10:14,260 --> 00:10:22,040 I always look at it to see not only the, I don't know, spread of DevOps and concerns that people have. 117 00:10:22,220 --> 00:10:32,780 And also the, I mean, basically the nut of it is that it shows you that DevOps is good, which, you know, big mystery there. 118 00:10:32,940 --> 00:10:43,440 But I think one of the other things that's interesting in the way that I tend to incorporate a lot of the DevOps report stuff into my ongoing prattle and presentation is there, I don't know what the technical term is. 119 00:10:43,440 --> 00:10:57,100 But there's a couple of flow chart-y things in there that show basically what it seems like good practices of DevOps are and how they lead to things like being able to do continuous delivery and lean management and lead to high-performing organizations. 120 00:10:57,860 --> 00:11:06,680 And I always like those charts, and I do this in kind of a jokey way in presentations, where you try to explain what DevOps is and usually leaves people with more questions than answers. 121 00:11:06,920 --> 00:11:16,520 And then, so you can go on to this and be like, well, this is actually a pretty good explanation of the components of DevOps and what it looks like when you're doing them from this more or less academic study. 122 00:11:16,640 --> 00:11:28,180 So, if you find those kind of, I don't know what they're called, big flow chart things, it gives you a good idea of what's in DevOps and the practices that you do to lead to succeeding, if you will. 123 00:11:28,780 --> 00:11:31,800 All that said, I haven't actually read this year's report yet. 124 00:11:31,800 --> 00:11:34,980 So, maybe if you've looked over it, you can give us the highlights. 125 00:11:35,920 --> 00:11:37,060 Yeah, I have read it. 126 00:11:37,240 --> 00:11:37,720 You know, it's good. 127 00:11:37,820 --> 00:11:41,540 Everyone loves a good infograph or giant chart-y thing or what have you. 128 00:11:41,560 --> 00:11:47,860 As you say, I mean, to some extent, again, I don't expect a state of DevOps report to tell me that DevOps is dying or that it's not going well. 129 00:11:48,000 --> 00:11:51,080 I think it's going to be positioned around probably a positive message. 130 00:11:51,080 --> 00:11:58,360 But, you know, last year's was known well for trying to tie DevOps to high-performing orgs and saying, look, you have happier employees. 131 00:11:58,960 --> 00:12:00,880 You actually had some financial benefits. 132 00:12:00,980 --> 00:12:02,540 It's hard to really correlate, I would think. 133 00:12:03,020 --> 00:12:03,860 Hey, I'm doing DevOps. 134 00:12:03,980 --> 00:12:05,420 Therefore, my company makes more money. 135 00:12:05,520 --> 00:12:07,380 There's got to be a lot of other variables in there. 136 00:12:07,780 --> 00:12:14,300 But, you know, this year's as well was focused on how does DevOps, again, fit into the overall life cycle. 137 00:12:14,300 --> 00:12:27,240 A lot of good numbers in there about deploying more frequency, you know, how much less time you're wasting on unplanned work when you have a more automation-driven culture where you've got some of this better collaboration. 138 00:12:27,400 --> 00:12:31,700 So I was trying to highlight what more you get out, how this fits into the rest of your life cycle. 139 00:12:31,940 --> 00:12:36,180 Again, for me, as sometimes a data junkie, there were almost too few data points. 140 00:12:36,180 --> 00:12:37,440 It was more of telling me a narrative. 141 00:12:37,800 --> 00:12:40,980 I really wanted even more data to find out, you know, tell me some of these things. 142 00:12:41,040 --> 00:12:42,560 Maybe give me the dark underbelly of DevOps. 143 00:12:42,740 --> 00:12:44,660 Like, tell me where you didn't see results you were expecting. 144 00:12:44,960 --> 00:12:50,040 I like getting some of that, especially because this is the most comprehensive survey, I think, of this space. 145 00:12:50,040 --> 00:12:51,960 It was almost 5,000 people interviewed this year. 146 00:12:52,340 --> 00:12:54,560 So it's a fantastic data source. 147 00:12:54,620 --> 00:12:55,400 They don't release it. 148 00:12:55,400 --> 00:13:08,040 But still, some nice findings if you're trying to prove to your company that this sort of model isn't just some fatty thing that, hey, you know, if we do this, we all get to wear T-shirts and, you know, get to ship to production as devs. 149 00:13:08,160 --> 00:13:10,680 Instead, it's about, wow, we actually have less unplanned work. 150 00:13:10,800 --> 00:13:11,840 We could be more secure. 151 00:13:12,040 --> 00:13:16,100 And as a company, we actually end up with better employee retention and higher performance. 152 00:13:16,280 --> 00:13:18,020 That's not bad to come out of it. 153 00:13:18,420 --> 00:13:28,080 Yeah, speaking of, like, wanting the raw pivot table, so to speak, did they detail how they select high-performing organizations more? 154 00:13:28,980 --> 00:13:38,840 Like, that was the part that I always missed is, like, I mean, I sort of understand from emailing with the people who did it how they sort of auto-select high-performing organizations. 155 00:13:38,840 --> 00:13:49,920 But it seems like connecting to, like, whether it's, like, revenue or profit or company valuation or things like that, there was always this missing chunk of high-performing. 156 00:13:49,980 --> 00:13:58,300 Because it's almost in a circular way where I think in previous ones, and I know it's not actual circular, but it seems that way to me, to my, like, philosophy major's mind. 157 00:13:58,400 --> 00:14:01,760 But, like, it's almost like high-performing means you're shipping a lot. 158 00:14:01,940 --> 00:14:04,180 But then in order to be shipping a lot, you need to be high-performing. 159 00:14:04,240 --> 00:14:08,680 And there's some sort of, like, crime mover that needs to be in that loop that helps define that. 160 00:14:09,360 --> 00:14:18,640 No, I don't remember seeing another clear definition this year, but it's funny you say that, because that would have been the example I would have given if you didn't, is it's focused on, yeah, who ships a lot, therefore you're high-performing. 161 00:14:18,660 --> 00:14:20,260 And you're only high-performing if you ship a lot. 162 00:14:20,320 --> 00:14:21,460 Like, it makes my face hurt. 163 00:14:21,700 --> 00:14:27,100 I think that there's probably other criteria besides those things, but probably good to call those things out. 164 00:14:27,100 --> 00:14:36,220 So when you do encounter skeptics, I'm sure if you drop the state of DevOps report on the skeptic, you know, lead of IT or chief architect's desk and say, see, read this, this is why we do DevOps, 165 00:14:36,860 --> 00:14:40,920 you also want to make sure you're hitting a lot of those counterpoints to try to refute some of those things. 166 00:14:40,940 --> 00:14:43,180 And you're going to do that with data, not just a great narrative. 167 00:14:44,080 --> 00:14:44,200 Yeah. 168 00:14:44,760 --> 00:14:47,120 Well, so I'll have to dive into that. 169 00:14:47,440 --> 00:14:54,280 And, you know, Nicole actually offered to meet up with me at DevOps Day Seattle to explain, answer all my questions. 170 00:14:54,280 --> 00:14:57,440 And I was lazy and did not talk with her. 171 00:14:57,940 --> 00:15:01,860 So I guess it's on my shoulders to fill out the footnotes that are in my mind. 172 00:15:02,400 --> 00:15:02,680 It is. 173 00:15:03,960 --> 00:15:05,100 So what else is going on? 174 00:15:05,280 --> 00:15:09,200 Notes, I hope footnotes in my mind is the title of your autobiography, honestly. 175 00:15:09,560 --> 00:15:10,020 That's right. 176 00:15:10,240 --> 00:15:13,700 Well, you know, I was at an EPA event just talking to them. 177 00:15:13,820 --> 00:15:21,620 They had their big, big normal mainstream summit and then the IT department symposium, as they call it, up in Chicago last week. 178 00:15:22,000 --> 00:15:28,040 And they had on the agenda, as with all great, like, memoir titles, this was unintentional. 179 00:15:28,120 --> 00:15:33,460 For lunch, it said, lunch on your own, which I thought was like, that was fantastic. 180 00:15:33,960 --> 00:15:40,120 That sounds like what I should call a certain part of any memoir should be titled that. 181 00:15:40,200 --> 00:15:41,720 But maybe footnotes in your mind. 182 00:15:41,780 --> 00:15:42,620 That would be good, too. 183 00:15:43,040 --> 00:15:45,060 I'll have to note these down for later. 184 00:15:45,460 --> 00:15:45,740 Absolutely. 185 00:15:45,900 --> 00:15:47,120 These are also good podcast titles. 186 00:15:47,260 --> 00:15:49,880 Lunch on your own is fantastic. 187 00:15:50,380 --> 00:15:50,520 Yeah. 188 00:15:50,780 --> 00:15:53,220 Well, what else has been going on this week that we should cover? 189 00:15:53,280 --> 00:15:53,480 Yeah. 190 00:15:53,580 --> 00:15:58,540 You know, the other one I want to point out was .NET Core got released to lead into our conversation with Kevin. 191 00:15:58,660 --> 00:16:11,280 But, you know, this is for the uninitiated, the foray by Microsoft into the open source space, meaning an actual version of the .NET framework that is completely open sourced, runs on Linux, runs on Windows. 192 00:16:11,800 --> 00:16:13,140 You know, it's pared down a little bit. 193 00:16:13,180 --> 00:16:17,640 It's not the full massive framework, but still most of the guts of what it is. 194 00:16:17,640 --> 00:16:25,140 But the idea being, look, I can be a Linux shop, a Windows shop, a commercial dev, open source dev, and I can build .NET apps. 195 00:16:25,740 --> 00:16:27,280 And so some tooling came along with that. 196 00:16:27,380 --> 00:16:30,760 Again, we'll talk about this a little bit with Kevin, but it was officially released last week. 197 00:16:30,840 --> 00:16:31,500 Big milestone. 198 00:16:32,500 --> 00:16:43,320 You know, there's some hand-wringing leading up to this final release is, you know, I guess any time you develop in public, you run the risk of changing decisions that people had already kind of started to do. 199 00:16:43,320 --> 00:16:47,980 And so there were just different changes in, hey, where do we store dependencies and how do we mention this? 200 00:16:48,040 --> 00:16:50,260 And they were learning and going along the way. 201 00:16:50,340 --> 00:16:57,580 And if it was closed sourced and it was just a big bang release, they would have had all these discussions in private and no one would have known and they would have just released software. 202 00:16:57,800 --> 00:17:03,760 But when you're constantly releasing versions and it's all open source, then you get more hand-wringing like, I can't believe this is madness. 203 00:17:03,920 --> 00:17:04,920 Nobody knows what they're doing. 204 00:17:05,180 --> 00:17:10,620 It's just funny where sometimes transparency gives you the illusion it's madness when it's probably been madness all along. 205 00:17:10,680 --> 00:17:11,520 You just didn't realize it. 206 00:17:12,880 --> 00:17:13,480 That's right. 207 00:17:14,020 --> 00:17:26,640 Yeah, I've been reading this book in the, what is it, in the Kingkiller Chronicles, like the name of the wind and everything about, and it's like this, about this one character who's clearly insane. 208 00:17:26,860 --> 00:17:37,660 And as I'm reading it, I'm wondering, like, if that's the premise of the book, she's just like has this obsessive compulsive disorder, but it's written in a way that makes you realize she's, you know, makes it seem not normal. 209 00:17:37,880 --> 00:17:40,880 But it doesn't start off with like, and this character is insane. 210 00:17:41,160 --> 00:17:42,560 Let's see how her mind operates. 211 00:17:42,740 --> 00:17:48,240 So sure, whenever you expose some insanity, it's always been there. 212 00:17:48,340 --> 00:17:49,480 It just seems more crazy. 213 00:17:49,740 --> 00:17:52,540 But so that, you know, maybe both of you can help me with this. 214 00:17:52,540 --> 00:17:55,460 I haven't paid attention to the .NET world in a long time. 215 00:17:56,140 --> 00:18:04,120 And I remember, I think the last time I closely paid attention to it was around when they were open sourcing it, which I don't really remember that is. 216 00:18:04,180 --> 00:18:05,920 But that's a good start from the summary. 217 00:18:06,080 --> 00:18:07,860 Like, where do they host it? 218 00:18:07,880 --> 00:18:11,160 Like, where is the open source, like, managed? 219 00:18:11,780 --> 00:18:12,960 Yeah, shockingly, it's GitHub. 220 00:18:13,380 --> 00:18:15,640 So, you know, go to GitHub, pull source. 221 00:18:15,780 --> 00:18:20,720 Again, you can use command line tools and other packages to pull it down for your Mac or Linux or Windows system. 222 00:18:20,720 --> 00:18:26,360 So, you know, trying to be fully in the ecosystem, which I think is admirable as they look at that. 223 00:18:26,420 --> 00:18:28,660 And actually, they've done some performance benchmarks as well. 224 00:18:28,780 --> 00:18:35,960 So last week during the kickoff, which they did at another delightful open source companies conference, but they did the kickoff. 225 00:18:36,080 --> 00:18:43,160 And one thing they were pointing out was performance that, hey, you know, three times is faster than Node or three times faster than Go, eight times faster than Node.js. 226 00:18:43,360 --> 00:18:44,700 And here was the actual benchmark. 227 00:18:44,880 --> 00:18:45,940 And that's also up on GitHub. 228 00:18:46,180 --> 00:18:56,240 So, you know, appreciate that they're trying to be fairly public with the info in the places we go, not using CodePlex, which was an old Microsoft repository, which is still online. 229 00:18:56,240 --> 00:19:01,860 But almost like the source forge of Microsoft, kind of pre-GitHub place to stick source control and things like that. 230 00:19:01,940 --> 00:19:07,500 They could have stuck it there and said we're Microsoft, but instead they stick it on GitHub and play the way everyone else does. 231 00:19:08,300 --> 00:19:12,880 And then if this was like core coming out, so what are the non-core things? 232 00:19:13,180 --> 00:19:14,900 I mean, the sort of highlights of them. 233 00:19:14,940 --> 00:19:17,100 What's all the stuff surrounding it? 234 00:19:17,600 --> 00:19:24,000 Yeah, Kevin, do you want to dig into that a little bit or else we can also do a Kevin intro, I guess, since this is going to jump right into what he likes talking about? 235 00:19:24,200 --> 00:19:24,560 Well, sure. 236 00:19:24,680 --> 00:19:25,520 So who are you, Kevin? 237 00:19:25,820 --> 00:19:26,560 What's your story? 238 00:19:27,460 --> 00:19:28,520 So I'm Kevin. 239 00:19:29,420 --> 00:19:31,140 That's pretty much the end of my story. 240 00:19:32,440 --> 00:19:39,140 I've been doing .NET development since before it was actually referred to as .NET. 241 00:19:39,140 --> 00:19:57,880 So I've been along for the ride and I've had the fairly unique experience of being able to professionally do .NET stuff as well as a whole bunch of other open source projects and in a whole bunch of different open source languages. 242 00:19:58,100 --> 00:20:09,740 So I've been able to see the developer experience from inside a Microsoft shop and inside Java shops and a whole bunch of other different types of environments. 243 00:20:10,880 --> 00:20:16,880 So the release of .NET Core is pretty huge. 244 00:20:16,980 --> 00:20:26,280 To me, the core 1.0 release is even more important than the original .NET 1.0 release. 245 00:20:27,120 --> 00:20:27,680 Wow. 246 00:20:28,100 --> 00:20:29,320 So why do you say that? 247 00:20:31,380 --> 00:20:40,340 So, I mean, you've already sort of touched on these points, but I mean, I think the biggest is that this is now the open source project. 248 00:20:40,880 --> 00:20:51,620 And, you know, you were talking about insanity, being able to see into the somewhat crazy mind of collective consciousness and things like this project. 249 00:20:52,500 --> 00:21:04,540 And, you know, that the downside is, like you said, you get people get to see the decision making process and they get to watch as things pivot from one design to the other. 250 00:21:05,040 --> 00:21:06,080 But they also get to contribute. 251 00:21:06,080 --> 00:21:06,560 But they also get to contribute. 252 00:21:06,560 --> 00:21:17,280 Part of the reason why there were so many changes along the way between release candidates is because of the involvement of the general public. 253 00:21:17,520 --> 00:21:28,240 So many of the developers that were going to be using this were submitting pull requests and issues on GitHub and having conversations directly with the engineering people. 254 00:21:28,240 --> 00:21:35,320 And that there is something that we've never had the ability to do with Microsoft stuff before. 255 00:21:36,100 --> 00:21:47,260 In the past, you know, we've had a few people who have, you know, been handpicked to go and talk to Microsoft once in a while and their input was considered. 256 00:21:47,260 --> 00:21:55,200 But this type of community project is unprecedented, I think, for Microsoft. 257 00:21:55,700 --> 00:22:03,280 As you mentioned, they tried to do this thing they called shared source, where the source code to .NET was made available. 258 00:22:03,800 --> 00:22:08,580 But there were legal consequences for actually having seen it. 259 00:22:08,720 --> 00:22:10,440 So no one even wanted to look at it. 260 00:22:10,760 --> 00:22:12,040 Oh, they'd get, like, contaminated. 261 00:22:12,880 --> 00:22:13,080 Yeah. 262 00:22:13,720 --> 00:22:16,220 Yeah, you'd get the smell and you'd never be able to get rid of it. 263 00:22:16,220 --> 00:22:28,980 I'm curious as to your take on whether this is just protectionist by Microsoft saying, I want to make sure that .NET shops don't get a wandering eye and start trying to use other open source languages on Linux. 264 00:22:28,980 --> 00:22:30,960 And instead, let's give them .NET everywhere. 265 00:22:31,280 --> 00:22:39,040 Or do you see other people who may have not been in the .NET ecosystem before now picking up .NET as a new language because .NET Core is available? 266 00:22:39,180 --> 00:22:39,740 Where do you see that? 267 00:22:40,020 --> 00:22:42,700 I think it's a little bit of everything. 268 00:22:43,160 --> 00:23:07,380 You know, if you look at the last, I don't know, the last couple of years worth of Microsoft's efforts when it comes to, you know, building and expanding the developer experience, I think they've realized that forcing developers to only develop on Windows and only deploy their code, their backend code on Windows servers is a hindrance. 269 00:23:07,380 --> 00:23:26,080 And if you look at, you know, just the act of attempting to maintain Windows servers in a cloud environment, I think everybody starts to realize that some of that stuff is just not as flexible as Linux. 270 00:23:26,080 --> 00:23:47,780 So having Linux as a deployment target for .NET code is extremely appealing to, as you said, existing developers that are working on legacy ASP.NET stuff now, as well as, you know, other developers that might be looking for different options. 271 00:23:47,920 --> 00:23:50,580 They don't want to use PHP, they don't want to use PHP or they don't want to use PHP or they might not want to use Node. 272 00:23:50,580 --> 00:24:07,500 So I think what it boils down to is they're trying to make sure that .NET developers are able to move forward into, you know, where the environment where everything is a microservice and everything runs in the cloud. 273 00:24:08,120 --> 00:24:11,440 And you can't do that by forcing people to run on Windows. 274 00:24:12,120 --> 00:24:17,560 So .NET running everywhere, I think, is step one towards that goal. 275 00:24:18,300 --> 00:24:36,340 And, you know, having more than just, you know, Java as your list of choices for running your backend code is, I think it's in their financial interest, but it's also in the interest of just keeping C Sharp and .NET in Mindshare. 276 00:24:36,340 --> 00:24:37,360 Yeah, that makes sense. 277 00:24:37,780 --> 00:24:45,840 You mentioned in your preamble that you've done a lot of work, not just in the Microsoft ecosystem, but across it, so other languages and such. 278 00:24:46,460 --> 00:24:50,220 What's your take on the Hello World getting started experience with Core? 279 00:24:50,320 --> 00:24:54,580 So if a listener here goes, that sounds kind of interesting, you know, what's the setup? 280 00:24:54,700 --> 00:24:56,260 Do they have to go download 50 things? 281 00:24:56,500 --> 00:25:02,420 You know, what would you, you know, how have you judged this against others when it comes to, okay, do I need an IDE? 282 00:25:02,800 --> 00:25:04,080 What is my command line interface? 283 00:25:04,500 --> 00:25:06,080 How hard is it to get stuff up and running? 284 00:25:06,080 --> 00:25:07,400 What's the scaffolding like? 285 00:25:07,780 --> 00:25:09,700 What's your take as you compare that with others? 286 00:25:10,600 --> 00:25:18,500 So I have a few rules that I try and apply when I'm looking at new languages and new technologies. 287 00:25:19,240 --> 00:25:24,200 And for a long time, Microsoft stuff has failed those rules. 288 00:25:24,200 --> 00:25:29,220 Like, one of the things that I try and look for is, do I need an IDE in order to use this language? 289 00:25:30,100 --> 00:25:38,540 Like, if I'm forced, if I can't build my application without physically sitting inside an IDE, I consider that a failure. 290 00:25:38,860 --> 00:25:46,220 I need to be able to build my app from the command line, and if I feel like it, I should be able to write all the code for my app in either BI or Emacs. 291 00:25:46,840 --> 00:25:52,560 And, you know, whichever one of those you prefer, we can let people have their religious words on later. 292 00:25:52,560 --> 00:26:09,500 So the thing about .NET Core is, and with all the other ones that you could compare it to, is I think it's kind of an unfair judgment to judge how easy it is to build Hello World. 293 00:26:09,860 --> 00:26:19,780 Because Hello World is not a production app, and Hello World is, it does nothing other than prove you can compile the smallest number of lines of code. 294 00:26:19,780 --> 00:26:29,320 So, for me, it's about how quickly can I get to the minimum scaffolding necessary to build a microservice. 295 00:26:31,060 --> 00:26:39,480 And for .NET Core, that is about 15 minutes. 296 00:26:39,860 --> 00:26:49,260 And I forget what the actual download time is, but it's remarkably simple to get running on a Mac. 297 00:26:49,500 --> 00:26:52,240 And it's even faster on Linux. 298 00:26:55,640 --> 00:27:00,740 Make of it what you will, but the Windows install experience for .NET Core is the slowest of the three. 299 00:27:03,020 --> 00:27:03,720 That's awesome. 300 00:27:04,280 --> 00:27:04,720 Okay. 301 00:27:05,160 --> 00:27:07,640 No, I mean, if that's the right criteria, it's not a... 302 00:27:07,640 --> 00:27:11,700 Sure, I get a Python Hello World or PHP Hello World up in no time. 303 00:27:11,800 --> 00:27:12,840 Does that really mean anything? 304 00:27:12,920 --> 00:27:16,780 Short of, maybe it piques your interest going, all right, I can actually start playing with this. 305 00:27:16,840 --> 00:27:17,120 But you're right. 306 00:27:17,300 --> 00:27:24,480 The real measure of maturity and usability is probably the, what does it take to get real-life things up and running? 307 00:27:24,580 --> 00:27:27,060 Which is probably why things like Spring Cloud have taken off. 308 00:27:27,420 --> 00:27:34,140 Yeah, we need a new, like, a new, like, reference Hello World, like, forgot password cycle. 309 00:27:34,460 --> 00:27:35,520 Maybe that would be good. 310 00:27:36,220 --> 00:27:43,100 That's sort of, like, most common thing that touches on all sorts of systems that, and sort of probably dings all the bells. 311 00:27:45,040 --> 00:27:45,480 Awesome. 312 00:27:45,700 --> 00:28:01,920 So, you know, it's interesting that you mentioned Spring Cloud, though, because in Spring Boot, one of the measures that I think is important is the distance, at least from code complexity point of view. 313 00:28:01,920 --> 00:28:06,140 The distance from Hello World to an application that does something meaningful. 314 00:28:07,140 --> 00:28:27,440 So, to go from the four or five lines of code that write Hello World to the console to a microservice that emits Hello World on a RESTful endpoint is, you know, I think it's like five or six lines if you don't count the curly brackets. 315 00:28:28,520 --> 00:28:45,820 So, that's a fairly important measure, because the amount of excess garbage that you have to pull in in order to get something meaningful done is usually an indicator of how frustrating it's going to be to build production apps in that language or in that environment. 316 00:28:47,520 --> 00:28:58,800 And with .NET Core, everything is modular, so you're no longer pulling in the sum total of all libraries to do all the things in Microsoft. 317 00:28:59,260 --> 00:29:04,560 It's, you pull in only the dependencies you need, and you write only the lines of code you need. 318 00:29:04,860 --> 00:29:08,940 It's shockingly terse. 319 00:29:11,720 --> 00:29:13,960 Yeah, which is, I mean, super powerful stuff. 320 00:29:14,060 --> 00:29:30,220 I mean, speaking of the Spring stuff, you've also had a hand in Steeltoe, which is the, to introduce kind of the .NET version of some of the Spring cloud things, hopefully also to help accelerate people who are in a .NET world, they get some of the springy goodness from that. 321 00:29:30,280 --> 00:29:31,800 Can you describe that project just a little bit? 322 00:29:32,800 --> 00:29:43,980 Yeah, so, I mean, the basic idea is that if you're building microservices, very few real-world microservices. 323 00:29:44,060 --> 00:29:46,700 This doesn't ever exist on their own in a vacuum. 324 00:29:47,420 --> 00:30:05,600 What people are really building is ecosystems of interconnected microservices, and once you start viewing your application as a participant in an ecosystem like that, you start to need other tools outside of just the basics. 325 00:30:05,800 --> 00:30:09,120 You know, how do I, you know, how do I, you know, how do I, how do I do RESTful routing? 326 00:30:09,120 --> 00:30:10,220 How do I do HTTP? 327 00:30:10,620 --> 00:30:15,540 It becomes things like, well, how do I store central configuration in a version-controlled way? 328 00:30:16,020 --> 00:30:20,560 How do I discover other microservices that I need to connect to? 329 00:30:20,660 --> 00:30:25,320 How do I advertise my own service so that other services can locate it? 330 00:30:25,380 --> 00:30:43,580 Things like that, and rather than reinvent the wheel as a crappier wheel, there are already plenty of incredibly powerful open source projects available for that in the Netflix OSS and Spring Cloud community. 331 00:30:43,580 --> 00:31:02,340 So, with SteelToe, it has, it's essentially just a couple of really lightweight libraries in keeping with the whole .NET Core feeling that allow your .NET code to consume those services as clients. 332 00:31:02,340 --> 00:31:14,340 So, using SteelToe, you can communicate with a Spring Cloud configuration server, you can discover, you can participate in service discovery with Eureka. 333 00:31:18,280 --> 00:31:23,340 And there's, there's plans to expand it beyond what, what I just mentioned. 334 00:31:23,880 --> 00:31:24,320 Sure. 335 00:31:24,480 --> 00:31:26,480 I don't know, I don't have the exact roadmap. 336 00:31:27,280 --> 00:31:34,000 No, it's exciting stuff for people who like the Spring Cloud model and, you know, you shouldn't be waiting around for Netflix to port their stuff to .NET. 337 00:31:34,140 --> 00:31:38,780 So, it's nice that we have a, trying to help that out and make that, that's something more powerful. 338 00:31:38,860 --> 00:31:39,220 That's awesome. 339 00:31:39,580 --> 00:31:50,940 Yeah, I think over the past three months, almost, not every time, but almost every time I talk with a, with, with a Pivotal customer or, or a Cloud Foundry user, they bring up SteelToe. 340 00:31:50,940 --> 00:31:55,660 And they, they ask if I, if I know when, when, when everything will be done and ready to use. 341 00:31:55,920 --> 00:31:57,100 They're very excited about it. 342 00:31:57,280 --> 00:32:02,980 Well, it's, it's, parts of it are up and ready to use now. 343 00:32:03,120 --> 00:32:05,680 It's, it's out there on GitHub for people to play with. 344 00:32:06,120 --> 00:32:11,020 And it has one of the better pieces of stock clip art out there, as you can imagine. 345 00:32:12,280 --> 00:32:14,180 The, the boots with the construction hat. 346 00:32:14,280 --> 00:32:14,580 Yes. 347 00:32:14,680 --> 00:32:21,680 It's, I think the, the, the logo for a project is as important, if not more important than the actual code. 348 00:32:23,600 --> 00:32:26,760 You've, you've got the first piece of open source already figured out. 349 00:32:26,840 --> 00:32:28,160 That's a, that's the secret there. 350 00:32:28,640 --> 00:32:28,860 Yes. 351 00:32:30,000 --> 00:32:31,380 So good. 352 00:32:31,440 --> 00:32:34,880 So, I mean, that kind of leads into, Coté, unless you had something else you wanted to dig into on that. 353 00:32:34,980 --> 00:32:38,400 I wanted to kind of switch as we think about Spring Cloud. 354 00:32:38,480 --> 00:32:39,500 We talk about microservices. 355 00:32:39,500 --> 00:32:41,180 We talk about .NET Core. 356 00:32:41,420 --> 00:32:53,100 I'm interested now in the, so you were, you were humble in your introduction, you know, while you talked about your, your sorted history with .NET and all the three letter acronyms of .NET world, like WPF and whatever else. 357 00:32:53,260 --> 00:32:57,040 You've also recently written a book, Beyond the 12 Factor App book. 358 00:32:57,040 --> 00:33:02,060 So that, you know, you could say, some people might say, well, I just get used to the 12 factors. 359 00:33:02,180 --> 00:33:03,620 Why are you already going beyond that? 360 00:33:03,880 --> 00:33:10,080 So you were building on some of the work that Josh McKenty and some others have done around some additional cloud-based factors. 361 00:33:10,420 --> 00:33:35,340 So, yeah, my job is to go out to customer sites and pair with their developers and get them to migrate their existing applications to the cloud. 362 00:33:35,340 --> 00:33:46,060 Whether that's, you know, just trying to lift an existing monolith out there or whether it involves a large amount of refactoring and re-architecting. 363 00:33:46,060 --> 00:33:55,620 So one of the questions that we get asked all the time is what makes an application cloud native or what are the 12 factors? 364 00:33:56,100 --> 00:34:07,100 And so rather than answering the same question over and over again, we thought it would be great if we had like a little handout or something that we could give to people to read. 365 00:34:07,100 --> 00:34:18,860 So that's essentially what, what started the, uh, the snowball downhill towards the, the application that's towards the book that, uh, we did through O'Reilly. 366 00:34:18,860 --> 00:34:38,040 Like, as far as the, the extra factors, um, I think it just comes from, um, a combination of just exposure to real world enterprise applications that, uh, have real problems that need to be fixed before they can run in the cloud. 367 00:34:38,040 --> 00:34:49,220 Um, and, uh, you know, uh, you know, I mentioned earlier that if you're, if you're building microservices, you're, you're, you're building an ecosystem of microservices. 368 00:34:49,220 --> 00:34:52,680 You're never really just building one microservice. 369 00:34:52,680 --> 00:35:22,120 And, uh, uh, that's sort of the, the motivation behind putting API first, uh, as the second factor there, um, it, you, you can't possibly overestimate the importance of, uh, managing the public APIs of microservices, especially when you have team organizations, um, lined up around microservice boundaries. 370 00:35:22,680 --> 00:35:41,740 You know, you might have one team working on one service, another one working on another, and they all have different release cadences and they have different internals and managing the public APIs so that the releases don't, one release doesn't break the other service and so on is critical. 371 00:35:42,800 --> 00:35:56,720 Um, so that's generally where the motivation for API first comes from, uh, the other one is, you know, most people just refer to it as, as logging or, uh, uh, auditing. 372 00:35:57,420 --> 00:36:10,920 And, uh, for the book, I wanted to try and convey more of the, the idea that the application that you're pushing into the cloud isn't something that you can physically touch. 373 00:36:10,920 --> 00:36:12,860 It's not sitting on your hard drive. 374 00:36:12,860 --> 00:36:18,660 It's not something that you can tether a debugger to it's, it could be on the East coast of the United States. 375 00:36:18,660 --> 00:36:19,820 It could be on the West coast. 376 00:36:19,820 --> 00:36:21,840 Next time you look, it could be running in Europe. 377 00:36:21,840 --> 00:36:30,020 It's the cloud model implies that the application is a remote thing. 378 00:36:30,020 --> 00:36:40,960 And so calling, referring to auditing as telemetry gives you, uh, you know, sort of the imagery that your application is a satellite that you've launched. 379 00:36:40,960 --> 00:36:52,620 And before you launch it, you need to know what information you want to get back from it in order to be able to tell whether it's operating properly, whether it's broken, how, whether it's performance is up to snuff. 380 00:36:52,780 --> 00:36:55,900 So that's, that's generally where those come from. 381 00:36:56,420 --> 00:36:56,460 Yeah. 382 00:36:56,480 --> 00:37:02,960 I mean, the logging one, I was listening to a podcast this morning and discussing some of Twitter's earlier challenges and how they scale. 383 00:37:03,040 --> 00:37:07,740 And again, those challenges with tracing and logging, once you don't know what failed or even where it failed anymore. 384 00:37:07,740 --> 00:37:14,920 And so, you know, as you think about tracing, you think about these services and these challenges that come up when you actually become 12 factor. 385 00:37:14,920 --> 00:37:23,220 I mean, as you've consulted and helped these customers, I mean, what are those things that now pop up as all right, you know, it seems like every solution to a problem always creates more problems. 386 00:37:23,220 --> 00:37:24,460 That's just the nature of things. 387 00:37:24,820 --> 00:37:30,480 What are some of those new problems that do come up once you start building these hyper distributed microservices apps? 388 00:37:30,480 --> 00:37:34,240 You touched on some of those, but other things you like to point out that, Hey, be careful. 389 00:37:34,240 --> 00:37:36,860 Now you have to think about management differently. 390 00:37:36,860 --> 00:37:39,080 You have to think about your deployment processes differently. 391 00:37:39,220 --> 00:37:44,420 You have to think, you know, what are those things that people might not always realize the first time they start getting into this model? 392 00:37:45,540 --> 00:37:45,900 Yeah. 393 00:37:45,980 --> 00:37:53,980 A lot of it comes from a lot of the stuff that I think is surprising to a lot of people is the day two stuff, you know, the operations. 394 00:37:53,980 --> 00:38:00,700 How do we, how do we care for and maintain the applications that are currently running in the cloud once we've gotten them there? 395 00:38:01,540 --> 00:38:06,480 Because that's, in many cases, that's a completely different model than the way it used to be. 396 00:38:06,580 --> 00:38:10,540 People are used to babysitting physical servers in a data center that they can walk into. 397 00:38:12,020 --> 00:38:31,700 And even if it's, even if they're maintaining their servers on virtual machines, a lot of people are used to having direct access to those and support and maintenance processes are all built around the notion that someone, whether it's an administrator or a security person or something, they have direct access to that machine. 398 00:38:31,700 --> 00:38:54,300 So, you know, figuring out what information you need to get out of the application, how the application can be remotely controlled and diagnosed, what are you going to do with the enormous amount of logs that are generated in the cloud usually comes up, too. 399 00:38:55,980 --> 00:38:56,500 Right. 400 00:38:57,260 --> 00:39:02,080 Logging and monitoring and metrics is, is always big. 401 00:39:05,160 --> 00:39:05,560 Yeah. 402 00:39:06,900 --> 00:39:07,860 Makes a lot of sense. 403 00:39:08,540 --> 00:39:12,860 Coté, I keep dealing in the opportunity for you to ask questions because I finally have this chance. 404 00:39:13,460 --> 00:39:13,980 Well, go ahead. 405 00:39:13,980 --> 00:39:27,240 Well, you know, one thing I was wondering about is, so, like, sometimes when I go out and talk with people, there's folks in the development team who have been doing, they still say, for example, 406 00:39:27,260 --> 00:39:32,680 J2EE instead of JEE, so they've been doing things the same way for quite some time. 407 00:39:32,680 --> 00:39:50,140 And I wonder, in your experience, like, when people switch over to more of a, I don't know, cloud-native-y way of doing things, and they have to start doing things in more of a 12-factor way, like, at the development level, like, what are some common, like, points of confusion or weird things that they screw up? 408 00:39:50,320 --> 00:39:54,680 Like, what's the transition like when you're going to more of a 12-factor way of developing? 409 00:39:54,900 --> 00:39:56,820 Or, or now that there's three, what would that be? 410 00:39:56,880 --> 00:39:57,620 15-factor. 411 00:39:58,460 --> 00:40:00,360 So, you mean from the developer's perspective? 412 00:40:00,660 --> 00:40:01,180 Yeah, yeah. 413 00:40:01,180 --> 00:40:01,560 Yeah. 414 00:40:01,680 --> 00:40:13,140 Like, how much, to phrase the question more concise, like, how much of a shift is it from zero-factor development or whatever pre-factor, pre-12-factor things is to, like, doing things in this way? 415 00:40:13,300 --> 00:40:20,440 Is it, like, difficult, or is it generally pretty easy, or, like, does it require, like, getting a new brain, or, like, how do people switch over to that? 416 00:40:20,480 --> 00:40:21,720 What's the experience they have? 417 00:40:23,720 --> 00:40:33,400 It completely varies, and it varies from customer to customer, and it'll even vary within, you know, different teams within the same customer. 418 00:40:33,400 --> 00:40:44,900 It just, it all depends on how people have built their applications and what assumptions they've baked in to the application about the environment that it's being deployed into. 419 00:40:45,860 --> 00:40:55,360 You know, things like changing the logging configuration of an application so that it writes the standard out, that's usually pretty easy for everybody. 420 00:40:55,500 --> 00:40:56,520 That's just yak shaving. 421 00:40:56,520 --> 00:41:15,920 And, but things like figuring out what stateless really means and why it's bad and what the, to violate that and what the consequences are, sometimes that's a fairly difficult change. 422 00:41:16,620 --> 00:41:33,820 You know, applications keep stuff in memory, and when the cloud decides that an application needs to switch from one running instance to four in order to handle load, a lot of people are completely surprised when the application stops working properly at that point. 423 00:41:33,960 --> 00:41:36,940 You know, you might have things like encryption keys that are stored in memory. 424 00:41:37,440 --> 00:41:57,300 So, one instance encrypts, the other one can't decrypt, and you have session states that could fail, and, you know, there's all sorts of ways that, ways of violating, all sorts of subtle ways to violate the stateless factor that are not really all that obvious. 425 00:41:57,300 --> 00:42:06,640 I mean, session state is the biggest, most obvious one, but it's the details that really kill people on stateless. 426 00:42:07,440 --> 00:42:21,180 Other ones are using the file system, or, you know, people are pretty comfortable with the idea that when you're pushing applications to the cloud, you don't want to write to the file system. 427 00:42:21,180 --> 00:42:33,620 But, you know, even then, applications, sometimes people write them to assume that they can read from it, or that if something exists on the file system, it'll always be there. 428 00:42:33,920 --> 00:42:37,000 And none of those assumptions are safe to make for cloud apps. 429 00:42:37,440 --> 00:42:55,640 Right. I always figured with that one, there's probably a lot of, like, frameworks and middleware that make a lot of assumptions about, like, even temporary files to do things, which sort of, like, is intellectually kind of cool, but could be dangerous at some point if they're relying on that. 430 00:42:56,740 --> 00:43:04,440 Yeah, people will, you know, a lot of wrappers or frameworks and libraries around some of these common tasks. 431 00:43:04,440 --> 00:43:11,800 And so, sometimes they're not even really aware that some dependency they have is violating one of these 12 factors. 432 00:43:12,180 --> 00:43:22,120 You could have an error logging or an error handling library, and it's writing some trace methods, some trace file to disk. 433 00:43:23,220 --> 00:43:25,940 Eventually, that could cause problems. 434 00:43:26,480 --> 00:43:33,480 Or, like, for a Windows app, it might be writing to the Windows event log or assuming that it has write access to the registry. 435 00:43:34,220 --> 00:43:40,580 Things like that are, you know, will cause problems for legacy apps. 436 00:43:41,140 --> 00:43:46,380 So, what are, like, common ways that people analyze transitioning things over? 437 00:43:46,520 --> 00:43:53,980 Like, are there, like, code analysis tools, or do they just sort of, like, you know, stick it out there on the track and see what blows up and then fix it incrementally? 438 00:43:54,180 --> 00:43:54,800 Or both? 439 00:43:56,560 --> 00:44:07,040 So, the approach my team generally takes is we are, we operate evidence-based and iteratively. 440 00:44:07,040 --> 00:44:18,660 So, in addition to analyzing the code, we'll deploy it to the cloud and see what breaks and then fix some things, deploy it again, and see what breaks the next time. 441 00:44:19,780 --> 00:44:26,300 And when we have it so that it's no longer breaking anything obvious, then that's where the hard part comes in. 442 00:44:27,660 --> 00:44:37,100 Because when the app appears to be running, you know, you could have subtle failures that you need to test for, which is why we, of course, encourage writing tests for things. 443 00:44:39,220 --> 00:44:40,300 Well, that makes sense. 444 00:44:40,720 --> 00:44:46,960 That way you can take advantage of both things, the blowing up and the more scientific approach, as it were. 445 00:44:47,920 --> 00:44:48,220 Mm-hmm. 446 00:44:51,280 --> 00:44:57,560 So, I mean, yeah, you talked a little bit about kind of what we're keeping aware of as we think about refactoring. 447 00:44:57,640 --> 00:45:10,160 I mean, how many times when you talk to people, Kevin, is it we're starting Greenfield with these things, or we want to start slowly 12-factoring, if we make a verb out of it, some of our existing apps? 448 00:45:10,220 --> 00:45:13,380 Do you see that, or do you see most of this being applied to fairly Greenfield stuff? 449 00:45:14,820 --> 00:45:25,820 So, I don't know if my sample size is necessarily a good representation of the entire field, but Greenfield is extremely rare. 450 00:45:26,300 --> 00:45:43,720 What I've encountered is everybody has an enormous inventory of legacy enterprise apps, and it becomes a trade-off between the business value of moving an application to the cloud 451 00:45:43,720 --> 00:45:51,780 versus how much time and effort it's going to take to factor away some of those things that are currently violating 12-factor. 452 00:45:52,460 --> 00:45:57,800 I think most devs would love to know they were just working on new hotness all the time, but that's just not reality. 453 00:45:58,000 --> 00:46:05,160 So, are there factors that you see people start with and say, look, this is not low-hanging fruit, but as you look at a monolithic code base, 454 00:46:05,160 --> 00:46:14,980 so you're starting to turn this into microservices, start thinking about externalizing your config, or start thinking about how you actually simplify the startup stop routines, 455 00:46:15,120 --> 00:46:20,400 or think about where do you see some of those where people, what are the ones you shouldn't start with, and which ones should you? 456 00:46:21,740 --> 00:46:24,260 Well, again, it really depends on the application. 457 00:46:24,960 --> 00:46:34,300 Just because something is violating a factor doesn't necessarily mean that the fix for it is automatically easy or difficult. 458 00:46:35,640 --> 00:46:40,580 I've actually seen applications where you would think that externalizing config should be easy, 459 00:46:40,760 --> 00:46:49,820 but depending on how it's written, you know, it could be spaghetti or tentacles that just are throughout the entire code base, 460 00:46:49,860 --> 00:46:53,000 so it's not as easy as just changing one config file. 461 00:46:53,000 --> 00:47:00,180 But some of the stuff that is usually low-hanging fruit is things like externalizing configuration. 462 00:47:02,220 --> 00:47:06,100 Enforcing statelessness on most apps is straightforward. 463 00:47:06,300 --> 00:47:13,960 It might be a lot of brute force coding to get it fixed, but it's pretty obvious how to fix it. 464 00:47:14,760 --> 00:47:22,180 There's, you know, making sure that the start and stop times are fast. 465 00:47:22,180 --> 00:47:26,300 Those are also pretty, usually pretty easy to take care of. 466 00:47:27,460 --> 00:47:30,880 But again, it all depends on the application. 467 00:47:31,100 --> 00:47:38,860 One of, I think, the ideal approaches that we've been recommending for certain types of apps is 468 00:47:38,860 --> 00:47:47,040 getting a legacy ASP.NET application to a point where it's not violating 12 factors, 469 00:47:47,160 --> 00:47:49,680 and it can run in the cloud, and you can scale it, and so on. 470 00:47:49,680 --> 00:47:53,260 And then once it's in that point, and it's running on Windows, 471 00:47:53,740 --> 00:48:02,880 then strangling that monolith and, you know, pinching off small pieces at the seams that can become microservices, 472 00:48:03,180 --> 00:48:06,640 and those pieces can be treated like Greenfield, 473 00:48:06,760 --> 00:48:11,400 and so you can write those in ASP.NET Core and take advantage of all the new stuff, 474 00:48:11,460 --> 00:48:12,820 as well as running that on Linux. 475 00:48:13,360 --> 00:48:17,080 Oh, that's a good tip of how to get started. 476 00:48:17,560 --> 00:48:18,660 It's a good thing to pick. 477 00:48:19,180 --> 00:48:19,500 Well, great. 478 00:48:19,620 --> 00:48:23,620 Well, thanks for being our second guest here on Pivotal Conversations. 479 00:48:23,900 --> 00:48:25,300 I think that was fun stuff. 480 00:48:25,580 --> 00:48:26,080 Do you have a... 481 00:48:26,080 --> 00:48:26,480 Very much. 482 00:48:26,580 --> 00:48:28,380 If people want to look you up, where should they go? 483 00:48:28,960 --> 00:48:31,360 You know, in a public way, not sort of in a spooky way. 484 00:48:32,800 --> 00:48:36,680 So, the non-stalker way to get a hold of me would be Twitter, 485 00:48:36,900 --> 00:48:41,920 at Kevin Hoffman, and my blog is cotancode.com. 486 00:48:42,880 --> 00:48:43,440 Well, great. 487 00:48:43,540 --> 00:48:47,220 And we'll put a link to the Beyond the 12 Factor app book. 488 00:48:47,420 --> 00:48:48,160 I think we... 489 00:48:48,160 --> 00:48:51,120 Well, I know we have it offered for free, so you don't even have to pay for it, 490 00:48:51,140 --> 00:48:53,060 which I guess is either good or bad for you. 491 00:48:53,380 --> 00:48:57,240 But it's a pretty brief book that you can go through, 492 00:48:57,500 --> 00:48:59,300 and it's got a nice cover on it as well, 493 00:48:59,500 --> 00:49:01,220 which, obviously, I'm way too visual. 494 00:49:01,660 --> 00:49:05,840 I've got a longer book that is not free coming out in a couple of months 495 00:49:05,840 --> 00:49:08,100 on building microservices in Go, 496 00:49:08,840 --> 00:49:11,220 and then a couple months after that, 497 00:49:11,300 --> 00:49:14,000 another one on building microservices in ASP.NET Core. 498 00:49:14,340 --> 00:49:14,620 Wow. 499 00:49:14,860 --> 00:49:16,660 You're way scheduled up there. 500 00:49:16,740 --> 00:49:17,540 That's fantastic. 501 00:49:18,840 --> 00:49:19,320 Awesome. 502 00:49:19,620 --> 00:49:20,060 Well, great. 503 00:49:20,060 --> 00:49:22,480 Well, as always, this has been Pivotal Conversations. 504 00:49:22,760 --> 00:49:26,380 You can find us by going to pivotal.io slash podcast, 505 00:49:26,840 --> 00:49:30,800 and we're also at SoundCloud at soundcloud.com slash pivotalconversations 506 00:49:30,800 --> 00:49:32,480 if you like to type long URLs. 507 00:49:33,060 --> 00:49:36,320 It's always nice if you want to go to iTunes and give us a review 508 00:49:36,320 --> 00:49:39,840 or even just click on stars if you're into that kind of thing. 509 00:49:40,160 --> 00:49:43,300 And if you want to reach out to us, I'm Coté in Twitter. 510 00:49:43,580 --> 00:49:44,380 And what's yours, Richard? 511 00:49:44,980 --> 00:49:47,360 Yep, and I'm at rseroter on Twitter, 512 00:49:47,360 --> 00:49:49,100 and we look forward to always hearing that feedback, 513 00:49:49,260 --> 00:49:50,160 like it, good or bad. 514 00:49:50,300 --> 00:49:51,600 Hopefully, you're enjoying this. 515 00:49:51,680 --> 00:49:54,880 If you have, again, suggestions for other smart people like Kevin, 516 00:49:54,940 --> 00:49:56,200 let us know who you'd like us to talk to. 517 00:49:56,560 --> 00:49:58,000 And we'll see everyone next time.