.NET and Beyond 12 Factors with Kevin Hoffman (Ep. 25)

Episode 12 · 2016-07-04 · 49:58 · SRT · archive.org · all Tanzu Talk

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. 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. 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? 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. Oh, yeah. And, you know, we have not taken advantage of the SEO. 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. Well, this week we have another guest on. You want to introduce yourself briefly, guest? Yeah, Kevin Hoffman. 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. It depends how much of, you know, how much you want to talk about on that stuff. 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. So with that, it's – I think, you know, while we published weekly, it's been a couple weeks since we recorded. And I think that one of the larger – we've got a couple of things to go over here.

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. And then also there was DockerCon. There was a good overview of their – in InfoQ. There's quite a bit of announcements that they had there, which is an interesting thing to track in the container world. 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. 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. I'm sure there were like 10 or 15% who were like vendors and other sort of like hanger-oners, if you will. 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. But they are interesting wet fingers in the wind to kind of just figure out the direction things are going. 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. It's something. Better than just staring at the wall. That's right. A little bit of early predictor. Yeah. A little help. And I saw – I mean basically like a lot of the other people in this space, they're essentially focusing a lot on orchestration. 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. Yeah. I mean, as you mentioned, InfoQ did a nice write-up there. I guess we should also plug the Coté article on InfoQ that's also been well-received on cloud and portability. But you're welcome, Coté. But yeah, the DockerCon stuff, it was good stuff. It was up here in Seattle. So it was the same time as our cloud-native roadshow up here. So you had a lot of techies descending on the Seattle area. And as you mentioned, there was some big stuff with the orchestration. 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.

Because now the company that is containers, if you will, is embedding orchestration into their product. Why would I go use something else? 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. 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. Anybody who thinks they've picked a winner yet is remarkably premature. 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. There's absolutely guarantee it. So interesting to see some of the hand-wringing. 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. Just don't be married to it, because odds are things will change. But other good stuff coming out of the conference, again, good tooling, some interesting stuff around security scanning. I think they finally shipped the betas for the Mac and Windows Docker tooling. So all good stuff. These conferences seem to be a good place for not just news, but then some nice technical hands-on stuff. And the more people that talk about microservices and containers and operational efficiency, the better. 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? Room temperature, like a pack of defrosted hot dogs being all July 4th themed. But, yeah, over on my other podcast, Software Defined Talk, we talked a lot about the DockerCon stuff. And, you know, we have two other people on there, one person who works at Chef and another who works at IBM. And the guy, Matt Ray, on there, he's always good at explaining what's going on in this container orchestration area. So there's I think the last three episodes actually has been me playing like dumb person. And as I am on this topic and basically just asking him to explain the layout and what's going on and everything. So there's there's some more in-depth conversation there. 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.

And they're the people who are the the stewards of cloud, the Cloud Foundry code. And I guess, you know, the other ephemera around it. They came out with a survey. This is released like a week and a half ago or so. I forget. Right. But recently. Yeah. And I forget the name of the company they worked with. But as you do with these survey things, they worked with some company and surveyed 711 or 711, just like the convenience store people. And if you look at the demographics, I think it's pretty interesting because it's spread across. It's basically bucketed out in thirds across company size. 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. 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. And then I think as a result, you see that that that widening of the aperture. I think that means making something bigger and not a big photography person. But you see you see more things considered in the full scope of how you're managing. People are managing infrastructure and using containers and all sorts of things like that. Yeah, I mean, these things can always be a tad self-serving, but I like that we're trying to think of me. It's fun to talk containers. It's fun to cover all these things in orchestration. We have to remember that this is still plumbing and this is stuff that's very complicated. We could try to simplify it with nice UX or, you know, simpler manifest. But, you know, figuring out the right way to do these things is not trivial. It's multi-page guides to get some of these things stood up right. So fun to see the surveys. Good to see people looking in this space. And I guess, as always, it's stay tuned to see where this thing stuff or where this stuff goes. 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. 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.

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. And people who hadn't used cloud yet or were evaluating it would always say security was a big deal. 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. 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. Or putting it another way, they worry about different things until they use it. So, similarly, in this survey, there's one question that basically buckets out people who are evaluating containers versus using containers. And it's not quite the same as the cloud security one, but, in fact, it's kind of the opposite. It's the concerns about managing containers go up when you actually use them versus when you're just evaluating them. So, it ends up being more complicated than people had anticipated, it seems. Yeah, isn't that true? That's a good segue into the second survey. So, the 2016 DevOps report came out. 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. And I think they started doing this at Puppet Labs however many years ago. And it's actually expanded to have all sorts of other people who back it and use it. 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. So, as she will joke when you see presentations, there's a lot more science in it than there was. And there's some slight revisions. So, it's actually, I think, a pretty good report. I always look at it to see not only the, I don't know, spread of DevOps and concerns that people have.

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. 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. 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. 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. 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. 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. All that said, I haven't actually read this year's report yet. So, maybe if you've looked over it, you can give us the highlights. Yeah, I have read it. You know, it's good. Everyone loves a good infograph or giant chart-y thing or what have you. 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. I think it's going to be positioned around probably a positive message. 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. You actually had some financial benefits. It's hard to really correlate, I would think. Hey, I'm doing DevOps. Therefore, my company makes more money. There's got to be a lot of other variables in there. But, you know, this year's as well was focused on how does DevOps, again, fit into the overall life cycle. 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.

So I was trying to highlight what more you get out, how this fits into the rest of your life cycle. Again, for me, as sometimes a data junkie, there were almost too few data points. It was more of telling me a narrative. I really wanted even more data to find out, you know, tell me some of these things. Maybe give me the dark underbelly of DevOps. Like, tell me where you didn't see results you were expecting. I like getting some of that, especially because this is the most comprehensive survey, I think, of this space. It was almost 5,000 people interviewed this year. So it's a fantastic data source. They don't release it. 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. Instead, it's about, wow, we actually have less unplanned work. We could be more secure. And as a company, we actually end up with better employee retention and higher performance. That's not bad to come out of it. Yeah, speaking of, like, wanting the raw pivot table, so to speak, did they detail how they select high-performing organizations more? 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. 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. 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. But, like, it's almost like high-performing means you're shipping a lot. But then in order to be shipping a lot, you need to be high-performing. And there's some sort of, like, crime mover that needs to be in that loop that helps define that. 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. And you're only high-performing if you ship a lot. Like, it makes my face hurt. I think that there's probably other criteria besides those things, but probably good to call those things out.

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, you also want to make sure you're hitting a lot of those counterpoints to try to refute some of those things. And you're going to do that with data, not just a great narrative. Yeah. Well, so I'll have to dive into that. And, you know, Nicole actually offered to meet up with me at DevOps Day Seattle to explain, answer all my questions. And I was lazy and did not talk with her. So I guess it's on my shoulders to fill out the footnotes that are in my mind. It is. So what else is going on? Notes, I hope footnotes in my mind is the title of your autobiography, honestly. That's right. Well, you know, I was at an EPA event just talking to them. They had their big, big normal mainstream summit and then the IT department symposium, as they call it, up in Chicago last week. And they had on the agenda, as with all great, like, memoir titles, this was unintentional. For lunch, it said, lunch on your own, which I thought was like, that was fantastic. That sounds like what I should call a certain part of any memoir should be titled that. But maybe footnotes in your mind. That would be good, too. I'll have to note these down for later. Absolutely. These are also good podcast titles. Lunch on your own is fantastic. Yeah. Well, what else has been going on this week that we should cover? Yeah. You know, the other one I want to point out was .NET Core got released to lead into our conversation with Kevin. 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. You know, it's pared down a little bit. It's not the full massive framework, but still most of the guts of what it is. 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. And so some tooling came along with that.

Again, we'll talk about this a little bit with Kevin, but it was officially released last week. Big milestone. 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. And so there were just different changes in, hey, where do we store dependencies and how do we mention this? And they were learning and going along the way. 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. 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. Nobody knows what they're doing. It's just funny where sometimes transparency gives you the illusion it's madness when it's probably been madness all along. You just didn't realize it. That's right. 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. 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. But it doesn't start off with like, and this character is insane. Let's see how her mind operates. So sure, whenever you expose some insanity, it's always been there. It just seems more crazy. But so that, you know, maybe both of you can help me with this. I haven't paid attention to the .NET world in a long time. 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. But that's a good start from the summary. Like, where do they host it? Like, where is the open source, like, managed? Yeah, shockingly, it's GitHub. So, you know, go to GitHub, pull source. Again, you can use command line tools and other packages to pull it down for your Mac or Linux or Windows system. So, you know, trying to be fully in the ecosystem, which I think is admirable as they look at that. And actually, they've done some performance benchmarks as well.

So last week during the kickoff, which they did at another delightful open source companies conference, but they did the kickoff. 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. And here was the actual benchmark. And that's also up on GitHub. 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. But almost like the source forge of Microsoft, kind of pre-GitHub place to stick source control and things like that. 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. And then if this was like core coming out, so what are the non-core things? I mean, the sort of highlights of them. What's all the stuff surrounding it? 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? Well, sure. So who are you, Kevin? What's your story? So I'm Kevin. That's pretty much the end of my story. I've been doing .NET development since before it was actually referred to as .NET. 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. 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. So the release of .NET Core is pretty huge. To me, the core 1.0 release is even more important than the original .NET 1.0 release. Wow.

So why do you say that? 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. 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. 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. But they also get to contribute. But they also get to contribute. 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. 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. And that there is something that we've never had the ability to do with Microsoft stuff before. 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. But this type of community project is unprecedented, I think, for Microsoft. As you mentioned, they tried to do this thing they called shared source, where the source code to .NET was made available. But there were legal consequences for actually having seen it. So no one even wanted to look at it. Oh, they'd get, like, contaminated. Yeah. Yeah, you'd get the smell and you'd never be able to get rid of it. 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.

And instead, let's give them .NET everywhere. 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? Where do you see that? I think it's a little bit of everything. 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. 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. 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. 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. 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. And you can't do that by forcing people to run on Windows. So .NET running everywhere, I think, is step one towards that goal. 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.

Yeah, that makes sense. 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. What's your take on the Hello World getting started experience with Core? So if a listener here goes, that sounds kind of interesting, you know, what's the setup? Do they have to go download 50 things? You know, what would you, you know, how have you judged this against others when it comes to, okay, do I need an IDE? What is my command line interface? How hard is it to get stuff up and running? What's the scaffolding like? What's your take as you compare that with others? So I have a few rules that I try and apply when I'm looking at new languages and new technologies. And for a long time, Microsoft stuff has failed those rules. Like, one of the things that I try and look for is, do I need an IDE in order to use this language? Like, if I'm forced, if I can't build my application without physically sitting inside an IDE, I consider that a failure. 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. And, you know, whichever one of those you prefer, we can let people have their religious words on later. 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. 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. So, for me, it's about how quickly can I get to the minimum scaffolding necessary to build a microservice. And for .NET Core, that is about 15 minutes.

And I forget what the actual download time is, but it's remarkably simple to get running on a Mac. And it's even faster on Linux. Make of it what you will, but the Windows install experience for .NET Core is the slowest of the three. That's awesome. Okay. No, I mean, if that's the right criteria, it's not a... Sure, I get a Python Hello World or PHP Hello World up in no time. Does that really mean anything? Short of, maybe it piques your interest going, all right, I can actually start playing with this. But you're right. The real measure of maturity and usability is probably the, what does it take to get real-life things up and running? Which is probably why things like Spring Cloud have taken off. Yeah, we need a new, like, a new, like, reference Hello World, like, forgot password cycle. Maybe that would be good. That's sort of, like, most common thing that touches on all sorts of systems that, and sort of probably dings all the bells. Awesome. 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. The distance from Hello World to an application that does something meaningful. 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. 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.

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. It's, you pull in only the dependencies you need, and you write only the lines of code you need. It's shockingly terse. Yeah, which is, I mean, super powerful stuff. 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. Can you describe that project just a little bit? Yeah, so, I mean, the basic idea is that if you're building microservices, very few real-world microservices. This doesn't ever exist on their own in a vacuum. 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. You know, how do I, you know, how do I, you know, how do I, how do I do RESTful routing? How do I do HTTP? It becomes things like, well, how do I store central configuration in a version-controlled way? How do I discover other microservices that I need to connect to? How do I advertise my own service so that other services can locate it? 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. 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.

So, using SteelToe, you can communicate with a Spring Cloud configuration server, you can discover, you can participate in service discovery with Eureka. And there's, there's plans to expand it beyond what, what I just mentioned. Sure. I don't know, I don't have the exact roadmap. 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. So, it's nice that we have a, trying to help that out and make that, that's something more powerful. That's awesome. 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. And they, they ask if I, if I know when, when, when everything will be done and ready to use. They're very excited about it. Well, it's, it's, parts of it are up and ready to use now. It's, it's out there on GitHub for people to play with. And it has one of the better pieces of stock clip art out there, as you can imagine. The, the boots with the construction hat. Yes. It's, I think the, the, the logo for a project is as important, if not more important than the actual code. You've, you've got the first piece of open source already figured out. That's a, that's the secret there. Yes. So good. So, I mean, that kind of leads into, Coté, unless you had something else you wanted to dig into on that. I wanted to kind of switch as we think about Spring Cloud. We talk about microservices. We talk about .NET Core. 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. You've also recently written a book, Beyond the 12 Factor App book. So that, you know, you could say, some people might say, well, I just get used to the 12 factors.

Why are you already going beyond that? So you were building on some of the work that Josh McKenty and some others have done around some additional cloud-based factors. 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. 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. 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? 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. 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. 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. 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. You're never really just building one microservice. 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.

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. 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. 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. It's not sitting on your hard drive. It's not something that you can tether a debugger to it's, it could be on the East coast of the United States. It could be on the West coast. Next time you look, it could be running in Europe. It's the cloud model implies that the application is a remote thing. 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. 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. So that's, that's generally where those come from. Yeah. 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. And again, those challenges with tracing and logging, once you don't know what failed or even where it failed anymore. 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. 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.

That's just the nature of things. What are some of those new problems that do come up once you start building these hyper distributed microservices apps? You touched on some of those, but other things you like to point out that, Hey, be careful. Now you have to think about management differently. You have to think about your deployment processes differently. 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? Yeah. 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. 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? Because that's, in many cases, that's a completely different model than the way it used to be. People are used to babysitting physical servers in a data center that they can walk into. 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. 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. Right. Logging and monitoring and metrics is, is always big. Yeah. Makes a lot of sense. Coté, I keep dealing in the opportunity for you to ask questions because I finally have this chance. Well, go ahead. 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,

J2EE instead of JEE, so they've been doing things the same way for quite some time. 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? Like, what's the transition like when you're going to more of a 12-factor way of developing? Or, or now that there's three, what would that be? 15-factor. So, you mean from the developer's perspective? Yeah, yeah. Yeah. 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? 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? What's the experience they have? It completely varies, and it varies from customer to customer, and it'll even vary within, you know, different teams within the same customer. 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. 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. That's just yak shaving. 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. 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.

You know, you might have things like encryption keys that are stored in memory. 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. I mean, session state is the biggest, most obvious one, but it's the details that really kill people on stateless. 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. 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. And none of those assumptions are safe to make for cloud apps. 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. Yeah, people will, you know, a lot of wrappers or frameworks and libraries around some of these common tasks. And so, sometimes they're not even really aware that some dependency they have is violating one of these 12 factors. You could have an error logging or an error handling library, and it's writing some trace methods, some trace file to disk. Eventually, that could cause problems. 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.

Things like that are, you know, will cause problems for legacy apps. So, what are, like, common ways that people analyze transitioning things over? 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? Or both? So, the approach my team generally takes is we are, we operate evidence-based and iteratively. 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. And when we have it so that it's no longer breaking anything obvious, then that's where the hard part comes in. 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. Well, that makes sense. That way you can take advantage of both things, the blowing up and the more scientific approach, as it were. Mm-hmm. So, I mean, yeah, you talked a little bit about kind of what we're keeping aware of as we think about refactoring. 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? Do you see that, or do you see most of this being applied to fairly Greenfield stuff? So, I don't know if my sample size is necessarily a good representation of the entire field, but Greenfield is extremely rare. 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

versus how much time and effort it's going to take to factor away some of those things that are currently violating 12-factor. I think most devs would love to know they were just working on new hotness all the time, but that's just not reality. 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, 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, 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? Well, again, it really depends on the application. Just because something is violating a factor doesn't necessarily mean that the fix for it is automatically easy or difficult. I've actually seen applications where you would think that externalizing config should be easy, but depending on how it's written, you know, it could be spaghetti or tentacles that just are throughout the entire code base, so it's not as easy as just changing one config file. But some of the stuff that is usually low-hanging fruit is things like externalizing configuration. Enforcing statelessness on most apps is straightforward. It might be a lot of brute force coding to get it fixed, but it's pretty obvious how to fix it. There's, you know, making sure that the start and stop times are fast. Those are also pretty, usually pretty easy to take care of. But again, it all depends on the application. One of, I think, the ideal approaches that we've been recommending for certain types of apps is getting a legacy ASP.NET application to a point where it's not violating 12 factors,

and it can run in the cloud, and you can scale it, and so on. And then once it's in that point, and it's running on Windows, then strangling that monolith and, you know, pinching off small pieces at the seams that can become microservices, and those pieces can be treated like Greenfield, and so you can write those in ASP.NET Core and take advantage of all the new stuff, as well as running that on Linux. Oh, that's a good tip of how to get started. It's a good thing to pick. Well, great. Well, thanks for being our second guest here on Pivotal Conversations. I think that was fun stuff. Do you have a... Very much. If people want to look you up, where should they go? You know, in a public way, not sort of in a spooky way. So, the non-stalker way to get a hold of me would be Twitter, at Kevin Hoffman, and my blog is cotancode.com. Well, great. And we'll put a link to the Beyond the 12 Factor app book. I think we... Well, I know we have it offered for free, so you don't even have to pay for it, which I guess is either good or bad for you. But it's a pretty brief book that you can go through, and it's got a nice cover on it as well, which, obviously, I'm way too visual. I've got a longer book that is not free coming out in a couple of months on building microservices in Go, and then a couple months after that, another one on building microservices in ASP.NET Core. Wow. You're way scheduled up there. That's fantastic. Awesome. Well, great. Well, as always, this has been Pivotal Conversations. You can find us by going to pivotal.io slash podcast, and we're also at SoundCloud at soundcloud.com slash pivotalconversations if you like to type long URLs. It's always nice if you want to go to iTunes and give us a review or even just click on stars if you're into that kind of thing. And if you want to reach out to us, I'm Coté in Twitter. And what's yours, Richard? Yep, and I'm at rseroter on Twitter,

and we look forward to always hearing that feedback, like it, good or bad. Hopefully, you're enjoying this. If you have, again, suggestions for other smart people like Kevin, let us know who you'd like us to talk to. And we'll see everyone next time.

Tanzu Talk · 🍕 Get more pizza.