1 00:00:00,000 --> 00:00:14,120 Hi, everyone. Welcome to Pivotal Conversations. I'm Jeff Kelly, and this week, Dorman and 2 00:00:14,120 --> 00:00:19,180 I chat with Cerner's Greg Meyer. Greg is a distinguished engineer at the maker of healthcare 3 00:00:19,180 --> 00:00:23,300 software, and in this episode, Greg talks about a new specification he helped develop 4 00:00:23,300 --> 00:00:28,080 to achieve interoperability and easier data movement between healthcare systems. He also 5 00:00:28,080 --> 00:00:32,020 explains how the company is modernizing its development practices to increase the pace 6 00:00:32,020 --> 00:00:35,780 of innovation, all for the benefit of patients and healthcare outcome. 7 00:00:44,680 --> 00:00:50,940 So Greg, maybe you can tell us about this specification reference implementation that you've been 8 00:00:50,940 --> 00:00:57,620 working on, just to get us up to speed on what is it? What is it intended to solve for 9 00:00:57,620 --> 00:00:59,480 society at large? 10 00:00:59,480 --> 00:01:06,880 Right. So just give a little bit of context here. So health IT, one of the kind of big 11 00:01:06,880 --> 00:01:13,120 movers in health IT over the past decade or so has been interoperability, and that's interoperability, 12 00:01:13,220 --> 00:01:18,620 it's got a lot of definitions. But in this context, it's really kind of moving information from one 13 00:01:18,620 --> 00:01:23,860 health system organization to another, and that's amongst a lot of other things. Typically, there's 14 00:01:23,860 --> 00:01:30,520 been a couple big standards organizations in health IT interoperability, those being HL7 and IHE. 15 00:01:30,520 --> 00:01:39,720 A lot of those specifications, the interface is built around those. They can be very complex in terms of 16 00:01:39,720 --> 00:01:46,800 configuration, the specifications themselves. So back in late 2009, there's actually one of the engineering 17 00:01:46,800 --> 00:01:54,560 fellows here at Cerner and a Gartner, one of the Gartner guys, were working on something that they 18 00:01:54,560 --> 00:02:01,660 wanted to do to be able to pass information very simply between two organizations and what they 19 00:02:01,660 --> 00:02:07,900 initially called that simple interop. And they wanted it to be built on top of some existing 20 00:02:07,900 --> 00:02:13,460 specifications. They could do structured or non-structured data. A lot of things inside of health IT are very, 21 00:02:13,560 --> 00:02:23,100 very structured. So one of the other things they did is in early 2010, there was a part of the federal 22 00:02:23,100 --> 00:02:30,760 government called ONC, Office of National Coordinator, and that's under a bigger umbrella of HH Health and Human 23 00:02:30,760 --> 00:02:36,840 Services, which I'm sure a lot of people are aware of them. They do Medicare, Medicaid, amongst a lot of other 24 00:02:36,840 --> 00:02:43,160 things. And they brought about 80 companies together all in one. This is kind of one of the first times that they 25 00:02:43,160 --> 00:02:49,180 initially tried to do this underneath this umbrella. And that's, hey, we're going to take the simple interop idea and 26 00:02:49,180 --> 00:02:56,500 we're going to go turn it into something real. With the goal being is we want a mechanism instead of these complex 27 00:02:56,500 --> 00:03:03,040 interfaces of sending information, let's just create a simple way to go do this. So the 80 companies met, we had various 28 00:03:03,040 --> 00:03:10,780 task force and work groups. Eventually, we came out with initial specification of what we thought we might want it to 29 00:03:10,780 --> 00:03:18,680 look like. We did a bake-off of about four implementations. Eventually, in the summer of 2010, we came to a 30 00:03:18,680 --> 00:03:25,800 conclusion that we're going to use SMTP and a few other things, some SMIME specifications. And what that allowed us to 31 00:03:25,800 --> 00:03:33,560 do is then start running with some reference implementations built off of those specs. And interestingly enough, it 32 00:03:33,560 --> 00:03:39,940 was the entire endeavor was what we called a duocracy. A lot of the folks writing the reference 33 00:03:39,940 --> 00:03:44,620 implementations were actually writing a lot of the specs and driving a lot of the specs. So it's very 34 00:03:44,620 --> 00:03:51,680 different than what we see in a lot of the IHE and HL7 interoperability task force where they have 35 00:03:51,680 --> 00:03:58,260 a lot of these spec writers and policy writers, and then they just drop a spec out there. And then maybe 36 00:03:58,260 --> 00:04:03,520 or maybe somebody may or may not write a reference implementation. But this was the total opposite where 37 00:04:03,520 --> 00:04:09,140 you got the guys doing the work, writing the implementations, doing a lot of the spec writing. So as 38 00:04:09,140 --> 00:04:15,040 the actual spec came out, we had a full working implementation out there. So what does the 39 00:04:15,040 --> 00:04:23,060 specification actually do? It's in the end, it's just a simple point to point standard where we can 40 00:04:23,060 --> 00:04:30,440 push information from one organization to another. Just using simple SMTP, it actually runs off of the 41 00:04:30,440 --> 00:04:38,660 exact same backbone internet that your email does today. So we didn't really invent anything new. 42 00:04:38,820 --> 00:04:45,340 We just put some security layers on top of it that kind of made it robust for healthcare. So it was 43 00:04:45,340 --> 00:04:51,960 a push type of specification where an organization that they needed to push some data to another, 44 00:04:52,360 --> 00:04:57,600 they just type in an email address, they push it, does some trust and some security verification, 45 00:04:58,360 --> 00:05:02,720 and can send that data. And there's a whole bunch of different use cases out there that you could now 46 00:05:02,720 --> 00:05:09,380 go utilize this for. And it was like transitions of care, referrals, we can go on and on and on. But 47 00:05:09,380 --> 00:05:15,180 that's the verbal diarrhea of the specification called the direct project. 48 00:05:15,180 --> 00:05:18,140 Direct project. Yeah, there's definitely, thank you for that 49 00:05:18,140 --> 00:05:24,240 sort of high level, how the sausage is made in terms of 50 00:05:24,960 --> 00:05:30,580 reference implementations in these specifications. It's interesting that this is a different way that 51 00:05:30,580 --> 00:05:36,920 things went about this in a different way than kind of in the past. It sounds like there's some 52 00:05:36,920 --> 00:05:42,140 advantages to having the reference implementation developed at the same time as the spec being 53 00:05:42,140 --> 00:05:49,140 defined so that it's actually usable. That sounds, that sounds, you know, almost kind of akin to, 54 00:05:49,140 --> 00:05:57,560 uh, you know, like having, having the developers actually write the tests before they write the 55 00:05:57,560 --> 00:06:02,480 code, that kind of notion of, instead of having these in two separate places, like collapse it into one. 56 00:06:04,160 --> 00:06:09,780 Yep. Yep. Absolutely. Yep. And, and it really did speed up. I, I think in terms of being able to turn 57 00:06:09,780 --> 00:06:16,540 this into a, um, into something that was usable by the public at large. I mean, you, you hear about a 58 00:06:16,540 --> 00:06:22,780 lot of these specifications taking years and years to write. We went from an idea to a 1.0 release version 59 00:06:22,780 --> 00:06:30,940 of the reference implementation in under a year and that included a, a consensus spec as well as a reference 60 00:06:30,940 --> 00:06:36,380 implementation. We actually did it so fast that, um, ONC, when they did their certificate, they write 61 00:06:36,380 --> 00:06:43,340 these health IT certification of specifications that all health IT vendors have to go. We went from an 62 00:06:43,340 --> 00:06:50,860 idea to actually be written into a health IT regulation in about 18 months, which is totally unheard of. 63 00:06:50,860 --> 00:06:58,460 Wow. Yeah. Um, yeah, it seems like the, the, the kind of the path to production, if you will, 64 00:06:58,460 --> 00:07:06,220 was, was streamlined in that case. So, you know, tell us kind of that, that all sort of happened in the, 65 00:07:06,220 --> 00:07:14,700 you know, early 2010s. Um, and so what's been happening since, and you recently put out a new 66 00:07:14,700 --> 00:07:20,380 reference implementation, um, but maybe you could kind of walk us through what, 67 00:07:20,380 --> 00:07:26,540 you know, your, your journey has been on, what your journey has been, um, in kind of arriving at the, 68 00:07:26,540 --> 00:07:27,420 the current version. 69 00:07:29,900 --> 00:07:36,820 Yeah, sure. Um, so this, this actually goes back almost a decade. Um, I, I actually didn't get 70 00:07:36,820 --> 00:07:44,700 introduced into spring until probably about 2008 or so. Um, I was working on another product and 71 00:07:44,700 --> 00:07:50,220 written on top of an ESB architecture and they were just getting ready to move into spring, 72 00:07:50,220 --> 00:07:55,420 you know, when they were coming out their latest version of their ESB software. And I looked at it 73 00:07:55,420 --> 00:08:01,500 initially, I think it was like spring 2.5. It was still, um, fairly newish, you know, with, 74 00:08:01,500 --> 00:08:09,420 you know, five years old or so, um, very verbose based very much in, in XML. Um, personally, 75 00:08:09,420 --> 00:08:14,700 I found it to be a little too verbose, a little hard to use. So I, I kind of shied away from it a 76 00:08:14,700 --> 00:08:21,500 little bit. And then when we started doing the reference implementation in 2010, I think we had 77 00:08:21,500 --> 00:08:26,620 spring three at the time, we, we kind of split off the two teams that wrote that, um, I handled the 78 00:08:26,620 --> 00:08:30,940 core spec and then another one was doing some configuration and those were some web-based apps. 79 00:08:31,740 --> 00:08:37,580 And they did all of that, um, with the spring XML, they did wars, you know, deployed in Tomcat. 80 00:08:38,460 --> 00:08:42,940 Um, again, I, I looked at the updated spec was still kind of shying away from it because, 81 00:08:42,940 --> 00:08:47,660 because I felt it was, it was very heavy, maybe hard to configure. So in the, in the core spec, 82 00:08:47,660 --> 00:08:52,060 that guy was looking for something lighter and I ended up going with anything. I went with Google 83 00:08:52,060 --> 00:08:58,060 juice, um, after working with it for a couple of years, you know, I actually found it being a lot 84 00:08:58,060 --> 00:09:05,580 harder than I thought it was going to be. Um, just, but it was lightweight. And then I think in like 85 00:09:05,580 --> 00:09:13,740 2012, the, the folks that were of the team that handled all the web UI stuff and web configuration, 86 00:09:13,740 --> 00:09:18,700 they actually left the, this, this was all open source, uh, volunteer projects. And now I gotta, 87 00:09:18,700 --> 00:09:25,260 I gotta, um, handle and, and own the entire stack. So I, I was forced to go actually learn spring at, 88 00:09:25,260 --> 00:09:30,700 at the state that it was at, or at least in the version that they put in there. Um, still shying 89 00:09:30,700 --> 00:09:37,420 away a little bit, still kind of early on, they were using still some 2.5 and 3.0 stuff, but I did come 90 00:09:37,420 --> 00:09:43,100 to get an appreciation of the declarative nature of spring at the time. It was a lot easy or pretty 91 00:09:43,100 --> 00:09:47,740 easy to make some changes specifically at like deployment time. I could write some scripting 92 00:09:47,740 --> 00:09:53,340 to do some things like that. Um, at, at the same time, because you know, this is a reference 93 00:09:53,340 --> 00:09:58,460 implementation. So it gets downloaded, um, by anybody who wants to go use it. You know, 94 00:09:58,460 --> 00:10:04,620 my company actually Cerner was using it as well. And you know, it's, it's a reference implementation. 95 00:10:04,620 --> 00:10:08,460 So I always make these analogies of reference implementations, you know, like reference 96 00:10:08,460 --> 00:10:12,540 hardware. If you look at folks that implement hardware, a lot of folks will put out a reference 97 00:10:12,540 --> 00:10:17,260 board. Um, you'll make some tweaks to it before you go into production. So it was the same thing 98 00:10:17,260 --> 00:10:22,700 with here. So we, we were kind of eating some of the dog food that I put out there, uh, making some 99 00:10:22,700 --> 00:10:27,900 tweaks so we could have our own Cerner or, uh, our own Cerner direct project specification. Again, 100 00:10:27,900 --> 00:10:35,020 it was, it was very Tomcat based. We, we were doing microservices sort of, you know, instead of what 101 00:10:35,020 --> 00:10:40,060 we think now of spring boot, we had all these little itty bitty little Tomcat apps. Um, and then 102 00:10:40,060 --> 00:10:45,660 for the core spec, we're using this product called Apache James, um, which was using some of the juice 103 00:10:45,660 --> 00:10:51,820 stuff. So we had kind of a polygon of spring and a whole bunch of Tomcat apps. And then the, 104 00:10:51,820 --> 00:10:57,900 the core direct specs still running in juice. Then in about, this was, I want to say February, 105 00:10:57,900 --> 00:11:04,780 2015 of, of all people, Josh Long came to Cerner and he gave us a presentation here on some of the 106 00:11:05,420 --> 00:11:09,420 great, you know, the latest status, latest and greatest stuff coming up in spring. And, uh, 107 00:11:09,420 --> 00:11:15,020 spring boot was only less than a year old. Uh, spring cloud was still an alpha and he gave 108 00:11:15,020 --> 00:11:22,940 us this great presentation, um, here in Kansas city on doing spring boot applications and using Netflix 109 00:11:22,940 --> 00:11:31,420 OSS spring cloud, um, spring boot configuration. And it just completely changed the way that we looked 110 00:11:31,420 --> 00:11:37,500 about doing our applications and doing our microservices. We're actually doing a rewrite of 111 00:11:37,500 --> 00:11:45,020 one of our, um, kind of like our, our male web client that sits over the top of our direct project 112 00:11:45,020 --> 00:11:51,100 implementation. We did a complete rewrite of that thing, um, using spring boot. And I still wasn't 113 00:11:51,100 --> 00:11:55,660 a big buyer into it. I actually wasn't part of that process. I was doing some other things. 114 00:11:56,380 --> 00:12:03,820 Um, so still, still hadn't bought into, into spring quite yet. Um, but then in about late 2016, uh, 115 00:12:03,820 --> 00:12:09,740 we got the call, uh, Brian Kelly and I did here of, Hey, we get to go cloud native. We can go pick 116 00:12:09,740 --> 00:12:15,820 whatever we want. And so we picked to go do PCF. And that's really when I jumped into spring boot, 117 00:12:16,300 --> 00:12:21,740 um, and, and got the latest and greatest stuff. I think it was spring four or something at the time. 118 00:12:22,620 --> 00:12:28,380 And as I wrote, did the deep dive into that completely changed my view on spring. I couldn't 119 00:12:28,380 --> 00:12:33,580 believe the number of updates that, that they had done in terms of the way that you do configuration. 120 00:12:33,580 --> 00:12:39,260 I mean, the fact that I didn't have to do XML anymore. Um, I had annotation based, um, configuration. 121 00:12:39,260 --> 00:12:45,740 Um, I could go do spring data. I could go write interfaces, um, for doing all my, my data access. 122 00:12:45,740 --> 00:12:52,540 And it just totally blew my mind. Auto configuration, um, was another big piece of that. So we took our 123 00:12:52,540 --> 00:12:58,060 implementation of, of Cerner, Cerner's direct implementation completely did the entire stack 124 00:12:58,060 --> 00:13:04,300 in, in spring boot. It was like 30, some 30 or 40, some, uh, microservice. And we've, we've got a 125 00:13:04,300 --> 00:13:11,660 lot of complex systems here. And we went, then we ended up going live with that just a few months ago. 126 00:13:12,460 --> 00:13:19,420 And ever since then, I mean, that, that jump into spring four and getting to do PCF and, and seeing 127 00:13:19,420 --> 00:13:25,340 the, the integration now that we could go do and writing applications a lot faster. And just, 128 00:13:25,340 --> 00:13:28,220 like I said, it completely changed my view of spring forever. 129 00:13:28,220 --> 00:13:32,140 Wow. Okay. So this was, no, this was the Cerner 130 00:13:32,140 --> 00:13:40,460 implementation based on specification, but the, the, the main publicly accessible reference 131 00:13:40,460 --> 00:13:48,220 implementation was, which you kind of maintained is this, that's the volunteer side. Um, now had, 132 00:13:48,220 --> 00:13:50,780 is what's that currently available in? 133 00:13:50,780 --> 00:14:00,860 Yep. So that's a great segue there. Um, so as we were doing a lot of these microservices for, 134 00:14:00,860 --> 00:14:05,260 for our implementation, we were having to kind of swizzle some of the reference implementation, 135 00:14:05,260 --> 00:14:09,180 because we're still a lot of our implementation still based off the reference implementation. 136 00:14:09,900 --> 00:14:16,540 Um, we had to swizzle those into kind of updating those components to, to work as spring boot 137 00:14:16,540 --> 00:14:22,220 app. So this actually happened at a SpringOne this pet, just this past year, a couple months ago, 138 00:14:22,220 --> 00:14:26,380 I was sitting in a lot of those sessions in there and just going through my head. 139 00:14:26,940 --> 00:14:30,940 Oh man, what just, I need to be putting these back in the reference implementation. I've, 140 00:14:30,940 --> 00:14:34,860 and I've really been wanting to do this for a long time and just never found the motivation or time 141 00:14:35,420 --> 00:14:40,460 to go do that. So actually at SpringOne, during one of the breaks, I sat down there, 142 00:14:40,460 --> 00:14:44,460 downloaded all the code and just kind of started from the bottom up all the way down at the, 143 00:14:44,460 --> 00:14:51,900 at the DAO layer and doing a comparison of, well, we've got all of these DAO implementation classes, 144 00:14:51,900 --> 00:14:58,860 just thousands of lines of code out here written in still in, uh, in spring three and started doing 145 00:14:58,860 --> 00:15:04,460 those, those migrations. And actually I tweeted some things out doing some side-by-side comparisons of 146 00:15:04,460 --> 00:15:10,460 the amount of code that we had to write with those old DAOs versus, um, the first one being spring data 147 00:15:10,460 --> 00:15:15,260 interfaces. And I was just literally going through and just deleting thousands of lines of code, 148 00:15:15,820 --> 00:15:22,220 um, and inside there, you know, making maintenance just so much easier. And over the, the past couple 149 00:15:22,220 --> 00:15:26,860 of months just started going through all the different layers of the stack. So, you know, we, we got rid 150 00:15:26,860 --> 00:15:33,100 of a lot of these old SOAP interfaces. Um, we did RESTful interfaces in JAX-RS. Um, all that got, 151 00:15:33,100 --> 00:15:38,140 uh, ended up moving into spring MVC and, you know, while we're doing it, might as well add in web flux 152 00:15:38,140 --> 00:15:43,180 in there as well. So we've got, um, you know, we, we have streaming interfaces in there. A lot of our 153 00:15:43,180 --> 00:15:47,740 RESTful clients that we had on the client side were all kind of all handwritten. We weren't even using 154 00:15:47,740 --> 00:15:53,660 REST templates, you know, shame on us for that. Um, but then we started moving that into FANE clients, 155 00:15:53,660 --> 00:15:59,100 you know, again, eliminating tons and tons of code. Actually the, the fun part with the FANE clients is 156 00:15:59,100 --> 00:16:05,740 a lot of that was just copy-pacing those spring MVC, um, definitions inside of the, inside of the, 157 00:16:05,740 --> 00:16:13,500 the microservices and just dumping them right into, into FANE interfaces. Um, authentication, you know, 158 00:16:13,500 --> 00:16:18,220 we had a lot of handwritten authentication, uh, spring cloud security ended up getting rid of that, 159 00:16:18,220 --> 00:16:24,780 uh, got rid of a lot of the XML configuration, uh, using annotations, um, the ability to pull in 160 00:16:24,780 --> 00:16:30,380 property files or sports, uh, spring cloud, uh, config if we wanted to, uh, we really wanted to 161 00:16:30,380 --> 00:16:36,220 modernize this, but also be backward compatible with the classic version, which was Tomcat and James. 162 00:16:36,220 --> 00:16:43,180 We realized if people were going to update to this new version, they still may want to go do, um, Tomcat, 163 00:16:43,180 --> 00:16:50,140 but they may want to go do, um, they may want to go do a spring boot microservices and maybe even PCF. 164 00:16:50,700 --> 00:16:56,300 So we, we found the ability to go take an existing more or something, you know, an end state and be 165 00:16:56,300 --> 00:17:03,100 able to run both at the same time. So we now had dual support of our classic mode and our, uh, um, 166 00:17:03,100 --> 00:17:08,220 microservices. So over here the past couple of months, we actually did last week or two weeks ago, 167 00:17:08,220 --> 00:17:13,260 a milestone one release of the reference implementation. That's completely modernized, 168 00:17:13,980 --> 00:17:21,020 modular microservices. Um, we've, we've actually pushed a lot of these out on, uh, um, pivotal web 169 00:17:21,020 --> 00:17:25,900 services. You know, I, I had lunch with James Watters out there at SpringOne. He was nice enough to 170 00:17:25,900 --> 00:17:31,660 allocate us some resources to go do this. So now we've got, uh, an entire reference implementation, 171 00:17:31,660 --> 00:17:37,820 not only running kind of in our pet VMs, but now fully running a complete stack out in pivotal web services. 172 00:17:38,220 --> 00:17:45,500 Okay. So for folks that are also in healthcare, specifically touching healthcare IT, 173 00:17:46,380 --> 00:17:54,700 and want to make use of this updated reference implementation, where should they go to take a 174 00:17:54,700 --> 00:18:01,420 look at it and kind of be able to start to play around with it? Is it a pivotal web service hosted 175 00:18:01,420 --> 00:18:06,540 version? Yeah. So there, there's, there's quite a few options. Number one, it's all open source. So all 176 00:18:06,540 --> 00:18:11,980 the codes out, it's still out there in GitHub. Um, we, we're moving it to a new organization now out 177 00:18:11,980 --> 00:18:18,620 there. So it's, uh, I think direct project RI is the, or direct project job RI is the, is the GitHub 178 00:18:18,620 --> 00:18:24,700 source. Uh, we post everything out on in Maven central repos. So there's like a, what we call an 179 00:18:24,700 --> 00:18:30,380 assembly project on all the microservices that are, they're out on the Maven. And then we also post out a, 180 00:18:30,380 --> 00:18:38,300 a, uh, a reference implementation, uh, installation guide out there. Uh, it's, I believe it's api.directproject.org 181 00:18:39,020 --> 00:18:44,620 and gives everybody, here's how you download it. Here's how you go install it. Um, my next part of 182 00:18:44,620 --> 00:18:49,820 the, the reference implementation is now updating everything. If somebody wants to go do it, the 183 00:18:49,820 --> 00:18:58,060 the microservices way, um, I do highly, um, recommend using something like cloud foundry or, or pivotal 184 00:18:58,060 --> 00:19:03,340 cloud foundry to go do that. Um, if somebody wants to go stand up their own cloud foundry and 185 00:19:03,340 --> 00:19:07,980 implementation, you know, you're absolutely free to go do so, you know, either using open source or, 186 00:19:07,980 --> 00:19:14,140 or going out and giving cloud foundry of the, or pivotal cloud foundry, the, the pivotal web services 187 00:19:14,140 --> 00:19:20,460 was, was a very nice way to, to go do this of trying to get the stood up. Um, especially if 188 00:19:20,460 --> 00:19:26,380 you're somebody that wants to go from a classic, um, you know, kind of home cloud hosted system, 189 00:19:26,940 --> 00:19:34,060 or even folks that are doing, um, public cloud, they kind of either take their existing VMs and 190 00:19:34,060 --> 00:19:38,860 just re-implement them or they'll do a lift and shift. But if they want to do a true cloud native 191 00:19:38,860 --> 00:19:44,940 stack, um, without a big cost of implementing, uh, you know, a whole bunch of VMs out there, 192 00:19:44,940 --> 00:19:49,500 uh, did some of the math on this, you know, it's like seven microservices that we had to push out 193 00:19:49,500 --> 00:19:55,980 there to do a full stack. Um, I think there were four services from the, uh, from the marketplace that 194 00:19:55,980 --> 00:20:01,900 we had to go pull in. And if, if you do the, if you do the cost comparison, it is just ridiculously 195 00:20:01,900 --> 00:20:05,740 how cheap you can actually go do this. Even if you did like an Amazon EC2 instance, 196 00:20:05,740 --> 00:20:09,980 you know, you're going to be paying, I don't know how many hundreds of dollars a month to, 197 00:20:09,980 --> 00:20:14,860 to go do that, but you're, you're really having to tend to it and, and really feed it like a pet. 198 00:20:14,860 --> 00:20:18,380 Whereas with, if you're doing the cloud foundry way, we just pushed it out there. 199 00:20:19,100 --> 00:20:23,420 Um, the deployment became very easy. We could integrate it with concourse for doing CICD. 200 00:20:24,700 --> 00:20:28,460 Um, I think the cost around that, and this was for the full stack and everything, 201 00:20:28,460 --> 00:20:32,540 you know, it was a few hundred, even below $1,000 a month, you know, depending on how much 202 00:20:32,540 --> 00:20:38,700 data that you wanted to go push through there. So, um, it'll be interesting to see how many folks 203 00:20:38,700 --> 00:20:45,100 want to start moving into true cloud native type of implementations versus a, versus a pet model, 204 00:20:45,100 --> 00:20:49,260 because it's, it's actually a lot easier to go run it and it's a lot cheaper than they think it might be. 205 00:20:49,260 --> 00:20:56,540 Yeah. So it seems like this kind of move to, you know, a, a fully kind of modernized and rewritten way 206 00:20:56,540 --> 00:21:03,820 of running the, the specification with this, with this reference implementation is sort of 207 00:21:03,820 --> 00:21:10,540 potentially a, an opportunity for folks to start to embrace, embrace a broader cloud native way of 208 00:21:10,540 --> 00:21:13,180 operating. Am I understanding that right? 209 00:21:13,180 --> 00:21:20,620 Yeah, absolutely. So you get not just the, the modernization of, of the architecture that makes 210 00:21:20,620 --> 00:21:26,620 it cloud native, but all, you know, all of the other things that kind of inherently or either 211 00:21:26,620 --> 00:21:32,380 consequently or inconsequently that come with that, that you may not think of, you know, and a lot of 212 00:21:32,380 --> 00:21:36,460 this comes around your, your day two pieces of it, of being able to do troubleshooting. You know, 213 00:21:36,460 --> 00:21:42,620 it's, it's amazing when we ended up moving to a cloud foundry, just how easy, how much easier and 214 00:21:42,620 --> 00:21:48,060 integrated and seamless it was to go do just the operational and support side of it. The deployment 215 00:21:48,060 --> 00:21:53,420 and configuration just becomes so much easier. I can't tell you how much time folks will spend just 216 00:21:53,420 --> 00:22:00,940 on configuration alone. You know, the CICD pieces of it. So you get, you just get so many different 217 00:22:00,940 --> 00:22:06,220 aspects of this that you just don't think of, of by going cloud native. 218 00:22:06,220 --> 00:22:11,180 So in that cost comparison that you were referring to, you know, help me understand that a little 219 00:22:11,180 --> 00:22:18,700 bit cleaner. What you were comparing, running this new reference implementation, you said you had it 220 00:22:18,700 --> 00:22:25,180 on some pet VMs. Were the pet VMs running PCF or was it, you know, you had to kind of manage the full 221 00:22:25,180 --> 00:22:25,820 stack there? 222 00:22:25,820 --> 00:22:30,860 Yeah, you had to manage the full stack. So when we first pushed out the reference implementation, 223 00:22:30,860 --> 00:22:38,140 we just threw out a Ubuntu EC2 instance out on Amazon. You know, it, it, it didn't have a lot 224 00:22:38,140 --> 00:22:43,260 of power. You know, these are a little micro service or a little, you know, micro instances out there. 225 00:22:44,140 --> 00:22:49,340 But, and, but if you wanted to go turn on a, an instance of this, there was just a lot of manual 226 00:22:49,340 --> 00:22:54,060 steps that you had to go do a lot of configuration that actually the documentation is, I don't know how 227 00:22:54,060 --> 00:23:00,860 many pages long of trying to turn these on or trying to turn these on. The cost for the EC2 instances 228 00:23:00,860 --> 00:23:05,340 themselves are not actually that much. It's when you start getting into a lot of the day two and 229 00:23:05,340 --> 00:23:10,700 the manual configuration, because honestly, that's where a lot of your cost is going to end up running 230 00:23:11,980 --> 00:23:17,020 from a day two perspective of, okay, I need to go do an update to this. What's that going to cost me 231 00:23:17,020 --> 00:23:25,020 from a personnel resourcing perspective versus if I want to go do this in a, in a pivotal web services, 232 00:23:25,020 --> 00:23:28,940 you know, if I, if I've got patch management or whatever, I'm going to go do the, the cost, 233 00:23:28,940 --> 00:23:33,820 that's really where the big cost comparison is going to hit. If, if you just start looking at here's an 234 00:23:33,820 --> 00:23:39,100 EC2 instance, you know, a couple of them that are going to run me, you know, to maybe 200 bucks a month 235 00:23:39,100 --> 00:23:45,900 versus I'm going to go run this out in Pivotal cloud or Pivotal web services might cost me 500 236 00:23:45,900 --> 00:23:51,660 a month. But what am I getting in terms of my total cost of ownership? And that's where that cost 237 00:23:51,660 --> 00:23:57,420 comparison really starts to show up where you've got to go do tending of pets and patch management and 238 00:23:57,420 --> 00:24:04,700 updating of databases and configuration versus you just kind of get that for free, free as in beer 239 00:24:04,700 --> 00:24:11,020 here, but you, you get a lot more of the, you don't have to spend so much resourcing, um, of trying to 240 00:24:11,020 --> 00:24:17,020 keep things up to date using cloud native, um, Pivotal web sources versus doing a pet tended system. 241 00:24:17,020 --> 00:24:23,500 Yeah. And if for folks that, you know, they could also, if they still wanted to be using, um, 242 00:24:23,500 --> 00:24:28,540 Amazon for their infrastructure, they could put cloud foundry or, or PCF on there and do the same 243 00:24:28,540 --> 00:24:33,900 thing. I'm kind of curious, but your recommendation for sort of looking at P dubs is just because, 244 00:24:33,900 --> 00:24:41,340 hey, it's already up and running. Um, it's a PCF environment that you can then push this 245 00:24:41,900 --> 00:24:47,580 reference implementation to quickly and you have all the day two taken care of already. 246 00:24:49,660 --> 00:24:54,620 Yeah. I mean, we, you know, we, we, we inside a CERN, we've, you know, we do stand up a pivotal 247 00:24:54,620 --> 00:24:58,460 cloud foundry out on, on Amazon. So that's definitely an option. But as you said, you know, 248 00:24:58,460 --> 00:25:04,060 the infrastructure here was already done. So, you know, trying to, trying to turn on the system. 249 00:25:04,060 --> 00:25:10,620 Now you don't have to go worry about allocating services, having to go get a PCF expert, uh, 250 00:25:10,620 --> 00:25:15,340 that knows how to go stand up a system. You know, we, there's a system already out there. So it was, uh, 251 00:25:15,340 --> 00:25:20,940 as we were writing, writing code, it was just, uh, a matter of going to the marketplace, 252 00:25:20,940 --> 00:25:26,300 turning on the three or four, you know, things that we need, just a quick CF create service 253 00:25:26,300 --> 00:25:31,340 instance. You know, it's, it's one command to go turn these on and then create a manifest and 254 00:25:31,340 --> 00:25:37,900 do a CF push. So it's, it's just night and day trying, trying to, trying to stand up a full, 255 00:25:38,620 --> 00:25:42,300 a fully implemented stack, you know, just using a few commands. 256 00:25:43,020 --> 00:25:47,580 And how does that trickle down to, uh, other things you can now do in, in your productivity 257 00:25:47,580 --> 00:25:48,380 and other areas? 258 00:25:51,220 --> 00:25:59,500 In, in terms of, uh, well, you know, in, in terms of doing CICD. So that that's one of our productivity 259 00:25:59,500 --> 00:26:05,340 pieces, you know, before in order to push something out, we were having to maintain a lot of chef scripts 260 00:26:05,340 --> 00:26:11,260 out there, which, you know, anytime we made a change to a, that we had to make a change to 261 00:26:11,260 --> 00:26:16,540 the system, we had to go man to maintain a chef script. Uh, then we had to go do all the chefy 262 00:26:16,540 --> 00:26:21,500 things that you have to go do of synchronizing up to a service, making things, um, up to date, 263 00:26:21,500 --> 00:26:27,420 and then go kicking those off on, on the nodes. Uh, whereas today in, in our, uh, system that we have 264 00:26:27,420 --> 00:26:32,620 now, you know, we utilize concourse and concourse is a very streamlined approach of going and doing that. 265 00:26:32,620 --> 00:26:39,180 And a lot of the things that we would have to go do in chef, um, just now become a, uh, 266 00:26:39,180 --> 00:26:43,900 natural side effect of just doing our pipelines and our day-to-day work. So we don't even think 267 00:26:43,900 --> 00:26:49,100 about, Hey, I need to go update this configuration chef. I mean, the, the pipeline just takes care of 268 00:26:49,100 --> 00:26:53,740 it. Um, if I want to go kick something off, you know, we've, we've got automated pieces that are 269 00:26:53,740 --> 00:26:59,020 automatically just running single commands out there as, as opposed to, uh, you know, these convoluted 270 00:26:59,020 --> 00:27:03,660 scripts to go, to go kick that off. So that that's just one aspect from the developer side. 271 00:27:04,540 --> 00:27:09,500 Um, you know, and, and we can get into, to all the day two pieces of it. You know, we, 272 00:27:09,500 --> 00:27:14,780 before when we were using chef, we kind of had two completely different implementations of, of chef 273 00:27:14,780 --> 00:27:19,740 set up one for development, uh, one for production. We had two different, completely different pipelines. 274 00:27:19,740 --> 00:27:24,460 We had one pipeline for development and then there's kind of like a kick it over the wall 275 00:27:25,100 --> 00:27:30,860 into the, into the production, you know, into the production guys. Now, now it's all streamlined. 276 00:27:30,860 --> 00:27:36,140 We just see everything as a, as one pipeline going through development and hitting those, 277 00:27:36,140 --> 00:27:41,820 those different aspects that they have to, you know, we're ISO, uh, 9,000 compliant and healthcare. 278 00:27:41,820 --> 00:27:45,660 So we've got to make sure we're meeting about regulatory pieces, but we just see it as one 279 00:27:45,660 --> 00:27:50,300 streamlined process that, that hooks all together. And we're not maintaining two different systems. 280 00:27:50,300 --> 00:27:52,700 It's just one pipeline from end to end. 281 00:27:52,700 --> 00:27:57,900 Yeah. That kind of seems to, um, set you up to avoid a lot of those issues of like, 282 00:27:57,900 --> 00:28:00,860 well, it worked in this environment and now it's not working over here. 283 00:28:00,860 --> 00:28:08,380 Yeah. That's, that's been one of the nicest parts of, I think of moving to concourse and PCF is as we 284 00:28:08,380 --> 00:28:13,820 look at what our development systems look like versus our production systems, they're almost 285 00:28:13,820 --> 00:28:18,620 completely identical, even all the way down to dev where we're doing some of our experimentation, 286 00:28:18,620 --> 00:28:23,660 you know, from an infrastructure perspective, it's all the same. You know, we're, we're allocating the 287 00:28:23,660 --> 00:28:31,100 exact same size of, uh, of services of being at databases or rabbit or Eureka or whatever else 288 00:28:31,100 --> 00:28:38,060 we're using out there, Redis. Um, and even, even the size of, of the machines themselves, you know, 289 00:28:38,060 --> 00:28:44,700 I, I did this, uh, I did this comparison of our, of our compute resources that we had previously when 290 00:28:44,700 --> 00:28:52,060 we did our pet systems versus PCF. We had a ton of all over allocation over to prod. And then we 291 00:28:52,060 --> 00:28:57,580 basically didn't get a lot of love back over to our, to our development system. So when, when we did 292 00:28:57,580 --> 00:29:03,660 the graphs of the number of nodes and compute and memory and everything, prod had those big, huge bars 293 00:29:03,660 --> 00:29:09,820 going clear up in terms of the number of CPUs, but dev was, you know, very, very small. So it's, it's 294 00:29:09,820 --> 00:29:13,900 kind of hard to get a one, you know, side set side to side comparison. As you said, you're tearing your 295 00:29:13,900 --> 00:29:17,980 hair out going, why, why is this not working? It, it, it works over here, but not there. And you just don't 296 00:29:17,980 --> 00:29:23,500 have that type of compute now in PCF. When we look at the, between the two, you know, our, our dev systems 297 00:29:23,500 --> 00:29:28,620 have roughly the exact same amount of power and compute that our production systems do. So it's, it, 298 00:29:28,620 --> 00:29:32,940 it's a lot easier now when we get those systems that we got to go toss back into dev that we really 299 00:29:32,940 --> 00:29:40,380 are talking about apples to apples. Yeah. I want to jump back a little bit to, you mentioned that 300 00:29:40,380 --> 00:29:49,180 you, you, you've recently gone live inside Cerner with the, the modernized implementation that's now you, 301 00:29:49,180 --> 00:29:58,860 you said 30 or 40 different microservices and you know, now running in, in spring, you rattled off a bunch of 302 00:29:58,860 --> 00:30:06,460 different aspects of spring, spring data, um, auto config, spring security that you have been able to 303 00:30:06,460 --> 00:30:15,740 bring in as part of this rewrite. Um, so how long, how long did this process take within Cerner to 304 00:30:16,780 --> 00:30:23,900 kind of change how you guys are, are implementing the, the, the specification and were there any other 305 00:30:23,900 --> 00:30:29,420 kind of lessons or surprises along the way as, as you kind of went down this path? 306 00:30:30,620 --> 00:30:37,340 Yeah. Um, so most of the things, like I said, they were running as a Tomcat apps before and had to 307 00:30:37,340 --> 00:30:44,940 bring them over to spring boot. It was actually a pretty painless process to go do the, probably the 308 00:30:44,940 --> 00:30:50,940 biggest part that we really had to be aware of was the configuration piece of it. Um, a lot of these 309 00:30:50,940 --> 00:30:56,140 being that they were Tomcat and they were getting pushed out via chef, which was copying configuration, 310 00:30:56,140 --> 00:31:02,700 you know, web XML files out there and properties files out there was trying to move that into a 311 00:31:03,580 --> 00:31:09,340 true cloud native configuration of being that being part of the, uh, the 12 factors out there. 312 00:31:09,340 --> 00:31:14,860 So if, you know, if anybody's looking at saying what's going to be the hardest part of trying to 313 00:31:14,860 --> 00:31:19,580 move from a legacy system over to a true cloud native system, and especially in spring boot, 314 00:31:19,580 --> 00:31:24,380 it's probably going to be, how are you doing your configuration and how do I need to wrap my mind 315 00:31:24,380 --> 00:31:28,460 around that? Cause that's, that's really going to be the hardest part of that. Um, there are some 316 00:31:28,460 --> 00:31:33,340 other things that we had to look at in terms of security configurations, just because we were 317 00:31:33,340 --> 00:31:40,300 previously running on prem, um, you know, running in a data center that was protected from the outside 318 00:31:40,300 --> 00:31:45,020 internet via, you know, firewalls, all that kind of things versus going out into public cloud. 319 00:31:45,020 --> 00:31:49,580 Uh, so a lot of, a lot of now security pieces that we didn't have to worry about, you know, 320 00:31:49,580 --> 00:31:56,380 we had to make sure we, all of our rabbit MQ connections were now using TLS, um, all of the 321 00:31:56,380 --> 00:32:02,140 end to end end points between all the microservices or part of our mesh were now all secured. 322 00:32:02,140 --> 00:32:09,180 Um, same thing we could say the exact same thing with my SQL, uh, previously trying to maintain a lot of 323 00:32:09,180 --> 00:32:13,660 those things would have been take, I don't want to say difficult, but there are other configuration 324 00:32:13,660 --> 00:32:19,340 things that we would then have to go worry about. Um, you know, with doing those as part of the 325 00:32:19,340 --> 00:32:25,020 marketplace now and, and just doing service bindings, it, it almost made it a no brainer to, to go do a lot 326 00:32:25,020 --> 00:32:31,020 of those. Um, some of the things with the service mesh of making those secure, um, we are using an 327 00:32:31,020 --> 00:32:35,820 older Oloth spec, um, to go make that happen, which a lot of these didn't have implemented. So we had to 328 00:32:35,820 --> 00:32:41,020 go turn that on. Um, we're now going to be looking, uh, probably sometime here in the near future, looking 329 00:32:41,020 --> 00:32:48,540 at Istio, which make, which could make that security layer a lot less, you know, a lot less complicated. 330 00:32:48,540 --> 00:32:52,300 We'd probably end up ripping out and doing like we did with the reference implementation, 331 00:32:52,300 --> 00:32:57,260 end up ripping out a bunch of this, you know, legacy Oloth code in there and just let Istio take 332 00:32:57,260 --> 00:33:01,660 care of that. Um, so those, that's probably the biggest three that we ran into. 333 00:33:01,660 --> 00:33:06,940 Okay. I think that's super helpful for folks to kind of just thinking through any of these kind 334 00:33:06,940 --> 00:33:14,780 of modernization projects to sort of know where they're going to be facing bigger hurdles and other 335 00:33:14,780 --> 00:33:19,500 places where, you know, they can sort of save themselves a lot of hassle, like the, the kind 336 00:33:19,500 --> 00:33:24,700 of notion of, um, you know, the, the service bindings and in general, like using the, the concept of 337 00:33:24,700 --> 00:33:31,500 service broker. So those types of changes to some of the dependent services can get updated in a more 338 00:33:31,500 --> 00:33:38,620 seamless manner. That sounds great. Keeping an eye out for, for config security. Um, and I, and I think 339 00:33:38,620 --> 00:33:44,300 that it's a testament that, you know, in the part of, as part of doing this, you also moved it into the 340 00:33:44,300 --> 00:33:53,340 public cloud, proving out that that's possible, um, and can, can be done in a secure fashion. So, uh, kudos 341 00:33:53,340 --> 00:33:59,820 to that. Yep. And, and it's, it's interesting you bring it with the configuration and, and the public 342 00:33:59,820 --> 00:34:03,580 cloud, you know, one of the, one of the other pieces I, I've, I forgot to mention here, you know, 343 00:34:03,580 --> 00:34:09,020 with the service brokers is, is the entire credential management, you know, it's, it's no secret that, 344 00:34:09,020 --> 00:34:15,660 you know, Cerner's now got contracts with, uh, with DOD and VA. So the, the, the scrutiny that we get 345 00:34:15,660 --> 00:34:21,100 around security audits is a lot higher. And, you know, that, that involves things like making sure you're 346 00:34:21,100 --> 00:34:27,100 doing proper credential rotation. I can't tell you how much time is actually spent on a lot of our 347 00:34:27,100 --> 00:34:32,780 systems that, you know, we've got, we may even have an entire team that maybe that's all they do is 348 00:34:32,780 --> 00:34:36,620 just making sure that we're doing credential rotation. You know, the service broker model just 349 00:34:36,620 --> 00:34:42,060 makes it a non-worry out there. You know, we, you know, we, we, we would have to go out there and 350 00:34:42,060 --> 00:34:46,780 making sure that we have our credentials in sync, you know, on these 40 microservices connecting to 351 00:34:46,780 --> 00:34:52,460 RabbitMQ or MySQL, uh, using service brokers, we don't even think about it anymore. You know, we, 352 00:34:52,460 --> 00:34:56,940 if, if we have to, if we've get a something coming down the line and a regulation that we have to go 353 00:34:56,940 --> 00:35:03,100 rotate these things every three months, that's okay, fine. We'll just go, we'll go add a blue green 354 00:35:03,100 --> 00:35:09,580 redeployment into a, uh, into a pipeline in, in production says redeploy this app every three 355 00:35:09,580 --> 00:35:15,340 months and boom, boom, we, we get auto, uh, we get auto credential management and rotation. 356 00:35:17,020 --> 00:35:23,820 Wow. Okay. So now to, to put this in some perspective for the, for lack of a better term, 357 00:35:23,820 --> 00:35:29,420 the community reference implementation that, that you work on as being kind of part of the, 358 00:35:30,220 --> 00:35:35,100 um, it's committee or I don't know what the right word is kind of going back to the, to the, 359 00:35:35,100 --> 00:35:40,940 to the whole sausage making, um, effort for, for building the spec and the reference 360 00:35:40,940 --> 00:35:45,740 architecture reference implementation. Um, you mentioned that you, you were really starting to 361 00:35:45,740 --> 00:35:52,300 dig into this at SpringOne platform. So late September this year, and you just had a milestone 362 00:35:52,300 --> 00:36:00,620 release a couple of weeks ago. So call it two months. Um, how, how long would that have taken you? 363 00:36:00,620 --> 00:36:08,860 Um, would you say in, in the past with, with the sort of, without, you know, the service broker model, 364 00:36:08,860 --> 00:36:14,140 without some of the, the kind of annotation model that, um, spring provides, et cetera, 365 00:36:14,140 --> 00:36:19,660 just, can you estimate like, what would that have, what, what amount of time when you would have had 366 00:36:19,660 --> 00:36:24,940 to figure out how to lay out volunteer wise for yourself in order to do that? 367 00:36:24,940 --> 00:36:30,860 Right. So when we did the first reference implementation, it took us roughly, I want 368 00:36:30,860 --> 00:36:36,700 to say seven months with three to four resources, um, working pretty much full time on this to, 369 00:36:36,700 --> 00:36:43,420 to, to bring this all, to bring this all up. Um, now moving over to the, uh, you know, 370 00:36:43,420 --> 00:36:47,260 it's a lot of the modernization things. And, and I should, I should also mention it, 371 00:36:47,260 --> 00:36:52,380 it took a lot of expertise across different domains and, uh, you know, different areas of, 372 00:36:52,380 --> 00:36:57,500 you know, people being able to write, uh, modularized components for, for a modern spec 373 00:36:57,500 --> 00:37:03,740 versus, uh, the web APIs and everything else. Um, so yeah, about seven months for resources, 374 00:37:03,740 --> 00:37:08,620 moving all this over to a modernization, um, piece of this, you know, it took one guy, 375 00:37:09,340 --> 00:37:16,780 you know, it took me about roughly two months working, maybe 50% on it, um, to do this modernization. 376 00:37:16,780 --> 00:37:22,220 And a lot of that, you know, not, not only do we have a, a modernized implementation, 377 00:37:22,220 --> 00:37:27,660 but I, I think we've greatly enhanced the ability of what we can do with the system in, 378 00:37:27,660 --> 00:37:34,060 in terms of deployment, in terms of, um, the ability to manage it. So Spring Boot not only 379 00:37:34,060 --> 00:37:38,620 brought the ability to, to really simplify the architecture, you know, I, I mentioned the thousand 380 00:37:38,620 --> 00:37:43,820 lines that, that we deleted in there. It doesn't take nearly the expertise now to, to go maintain 381 00:37:43,820 --> 00:37:48,620 these, you know, for example, somebody tracing through a, a DAO implementation. Well, now it's 382 00:37:48,620 --> 00:37:53,580 just an interface. So you, you don't even have to go worry about that anymore. Um, as well as all 383 00:37:53,580 --> 00:37:58,620 of the other day two production things that, that you just get out of the box from, from Spring Boot. 384 00:37:58,620 --> 00:38:03,580 You know, if, if we had to go write all of the things, you know, I think of the, the actuators, 385 00:38:03,580 --> 00:38:09,500 the micrometer pieces, um, integration into, into other subsystems, you know, like PCF metrics. 386 00:38:09,500 --> 00:38:15,900 And that would, I, I can't even, I can't even put the, how long or substantiate the amount of effort 387 00:38:15,900 --> 00:38:21,740 it may have taken, uh, this team to go put together these, these production pieces, you know, 388 00:38:21,740 --> 00:38:27,180 those things that make a production system, a true production system. Um, had we not had, uh, 389 00:38:27,180 --> 00:38:31,740 Spring Boot too, where now we get all that out of the box. And, and I, you know, that, that's one of 390 00:38:31,740 --> 00:38:36,540 the arguments I have with people that say, well, oh, Spring Boot, that's just too heavy. You know, 391 00:38:36,540 --> 00:38:41,580 just, just go turn this out into a, into a used go. And you can just quickly turn this into something 392 00:38:41,580 --> 00:38:46,460 you can go deploy out there and like, yeah, you can deploy that out there, but now how are you going 393 00:38:46,460 --> 00:38:49,820 to go manage it? How are you going to operate it? How, how are you going to measure it? What, 394 00:38:49,820 --> 00:38:55,820 what do you get out of the box, you know, using a, a small go application compared to what you get out 395 00:38:55,820 --> 00:39:01,260 of the box of a Spring Boot 2 application? It's, it's really hard to compare the two because you 396 00:39:01,260 --> 00:39:06,060 just really can't quantify it that well. There's, there's so much more that, that you get out in 397 00:39:06,060 --> 00:39:14,060 terms of, in terms of being able to, to measure, deploy a monitor, um, that, that you just can't do 398 00:39:14,060 --> 00:39:17,740 without using something like Spring Boot 2, or I should say that you just can't do very easily 399 00:39:17,740 --> 00:39:23,500 without a lot of effort. Yeah, no, that's, um, that's taking the long view, which, um, 400 00:39:23,500 --> 00:39:30,380 which I always appreciate. So, uh, one last question for me is, you know, now that, that you're able to 401 00:39:30,380 --> 00:39:37,500 kind of crank through, you know, modernizing a reference implementation over here and in a fraction 402 00:39:37,500 --> 00:39:45,020 of the time and effort, um, what's, what's next? What are you working on these days? Um, what are you, 403 00:39:45,020 --> 00:39:51,260 what are you looking forward to, to getting out? Oh, great question, boy. Um, a lot of what I'm 404 00:39:51,260 --> 00:39:56,060 doing is, is, is day to day, you know, I've, I'm the, the next piece is going to be taking this 405 00:39:56,060 --> 00:40:00,940 implementation. We obviously get documentation. Everybody seems to forget about the documentation 406 00:40:00,940 --> 00:40:06,300 part of, of this. So we're, we're going to go document, document this. We're going to go evangelize 407 00:40:06,300 --> 00:40:14,620 it. Um, there's, there's some other specifications, um, that are being utilized today inside of, uh, 408 00:40:14,620 --> 00:40:19,900 health IT. You know, one of the big ones out there is something called FHIR, F-H-I-R. It's 409 00:40:19,900 --> 00:40:24,380 fast, something, boy, I'm embarrassed. I can't remember what it talks about, but it's basically 410 00:40:24,380 --> 00:40:29,980 a restful way of, of being able to, to move data from one way to the other. It's kind of a poll, 411 00:40:29,980 --> 00:40:37,020 or it's a kind of a poll model, a request reply model of being able to evangelize some of these 412 00:40:37,020 --> 00:40:43,180 things of, of the, of what we've been able to do of being able to deploy services, not just for this 413 00:40:43,180 --> 00:40:48,700 reference implementation, but then moving these into other pieces of, of the healthcare architecture. 414 00:40:48,700 --> 00:40:55,180 So FHIR being one of those, um, we have a lot of other systems inside of our inter, interoperability 415 00:40:55,180 --> 00:41:01,740 space where I work here at Cerner. Um, things like doing e-prescribing, um, some other HL7 416 00:41:01,740 --> 00:41:07,260 transactions out there and modernize, modernizing those infrastructures as well. So what we did with 417 00:41:07,260 --> 00:41:12,860 direct project and, uh, a couple other systems in here inside of Cerner, which is kind of step one 418 00:41:12,860 --> 00:41:18,380 of proving out that, look, we can, we can take these systems and we can turn these 419 00:41:18,380 --> 00:41:23,820 into cloud native, uh, applications. We can push them out in the, in the, uh, in the public cloud. 420 00:41:24,460 --> 00:41:29,740 Um, we can operationalize them. I can't tell you actually how the amount of time that, uh, 421 00:41:29,740 --> 00:41:35,660 that we've reduced from our, from our operational side. So now trying to evangelize this in, inside 422 00:41:35,660 --> 00:41:39,980 of Cerner and actually try to take this out to some of the other implementations. If I can, 423 00:41:39,980 --> 00:41:45,980 this is going to be a hard fight, uh, with some of the other folks in, inside of HL7 or, or IHE and 424 00:41:45,980 --> 00:41:51,820 see if they can adopt, uh, reference architectures, um, inside of their organizations as well. 425 00:41:51,820 --> 00:41:58,060 Well, that sounds like an exciting path ahead. Where can folks follow you and, and sort of 426 00:41:58,060 --> 00:42:01,900 see how you're, you're coming along in this, uh, this adventure you've got for yourself? 427 00:42:01,900 --> 00:42:07,740 Yep. Um, they can generally find me out on LinkedIn and Twitter, uh, Twitter, uh, I believe my handle 428 00:42:07,740 --> 00:42:13,260 is Greg underscore Meyer 93. I think I'm violating something there with, uh, using an underscore, 429 00:42:13,260 --> 00:42:20,780 uh, and also LinkedIn. Uh, I think it's LinkedIn is Greg Meyer health IT. So I, I try to blog out 430 00:42:20,780 --> 00:42:25,340 there when I can, I don't get to do it nearly enough, but, um, as this milestone comes out, 431 00:42:25,340 --> 00:42:30,060 uh, you'll be catching a lot more of me out there. Well, I have learned a tremendous amount, 432 00:42:30,060 --> 00:42:35,100 both about, um, just kind of the, the general concepts around these specifications and how 433 00:42:35,100 --> 00:42:41,020 they're used, but also this, this pretty interesting journey that, uh, you've been on and that this 434 00:42:41,020 --> 00:42:47,020 particular, the direct project has been on, um, really exciting stuff and looking forward to hearing 435 00:42:47,020 --> 00:42:53,260 more. So we'll be make sure to include in the show notes links to the, the Maven repo and, and GitHub, 436 00:42:53,260 --> 00:43:01,500 um, for, for the direct, um, project so that folks can try it out. Awesome. All right. Thank you so much. 437 00:43:01,740 --> 00:43:02,300 Thank you.