WEBVTT 1 00:00:06.120 --> 00:00:09.080 Hey everybody, and welcome to another episode of the Ruby 2 00:00:09.160 --> 00:00:12.359 Rogues podcast. This week, on our panel we have Dave Kamia. 3 00:00:12.599 --> 00:00:16.120 Hey everyone, I'm Charles max Food from duv chat dot tv. Dave, 4 00:00:16.160 --> 00:00:17.920 It's nice to do a podcast with you again. 5 00:00:18.440 --> 00:00:19.719 It's been a while, hasn't it. 6 00:00:20.320 --> 00:00:22.960 I know, I keep winding up showing up when you 7 00:00:23.000 --> 00:00:24.640 can't make it, and then you show up when I 8 00:00:24.679 --> 00:00:28.000 can't make it. Yeah, of course now we both show 9 00:00:28.079 --> 00:00:31.559 up and Luke and John can't make it. So one 10 00:00:31.600 --> 00:00:33.719 of these days we also have a special guest, and 11 00:00:33.759 --> 00:00:35.119 that's Darren Bromer. 12 00:00:35.240 --> 00:00:36.359 Did I say that right, Darren? 13 00:00:36.640 --> 00:00:40.200 Yeah, Darren Bramer, Yeah, Bramer. Ah, I had a oe, 14 00:00:40.520 --> 00:00:42.719 said German. German a sound. 15 00:00:43.119 --> 00:00:44.560 Ah nice, sou. 16 00:00:44.719 --> 00:00:46.560 Do you want to introduce yourself, let people know who 17 00:00:46.640 --> 00:00:48.560 you are while you're important and famous and all that 18 00:00:48.600 --> 00:00:49.200 cool stuff. 19 00:00:50.200 --> 00:00:52.159 Absolutely? Yeah. Well, first of all, thanks a lot for 20 00:00:52.200 --> 00:00:53.920 having me on here. It's great to talk with you guys. 21 00:00:54.479 --> 00:00:57.640 So I've been engineer engineering my whole life. I will 22 00:00:57.679 --> 00:01:00.479 admit that I discovered Ruby a little bit later in 23 00:01:00.520 --> 00:01:02.960 my career. I was the Java guy for quite a 24 00:01:03.039 --> 00:01:06.280 while and going all the way back to two thousand 25 00:01:06.319 --> 00:01:08.239 and two, I'm going to date myself here. I wrote 26 00:01:08.239 --> 00:01:12.560 a book on Java J twoee. Actually, so there you go. 27 00:01:12.920 --> 00:01:16.239 There's a data bit of technology a little bit, and 28 00:01:16.280 --> 00:01:19.799 so I've done all types of engineering managed teams. I 29 00:01:19.840 --> 00:01:22.840 decided I wanted to go back get hands on keyboard. 30 00:01:22.879 --> 00:01:26.280 After doing that, went to Amazon Web Services, had a 31 00:01:26.319 --> 00:01:30.159 great time working there, learned a whole lot, had a 32 00:01:30.200 --> 00:01:32.239 lot of fun, met a lot of great people, and 33 00:01:32.280 --> 00:01:34.640 then wanted to get more into kind of combined the 34 00:01:34.640 --> 00:01:37.719 two things I really really enjoy, so the technology obviously, 35 00:01:37.760 --> 00:01:41.519 but also communications. And so now I kind of kind 36 00:01:41.560 --> 00:01:44.519 of went and switched gears of now the developer evangelist 37 00:01:44.599 --> 00:01:48.000 for engine Yard, and we have platforms of service tools. 38 00:01:48.040 --> 00:01:49.879 But I get to do my two favorite things, which 39 00:01:49.879 --> 00:01:53.680 are play with technology and share that with people, write 40 00:01:53.680 --> 00:01:54.920 about it and talk about it. 41 00:01:55.079 --> 00:01:55.519 Awesome. 42 00:01:55.560 --> 00:01:58.159 And yeah, we ran across this article from you talking 43 00:01:58.200 --> 00:02:03.400 about architecture and micro services and stuff, which is funny 44 00:02:03.439 --> 00:02:05.840 because I think on JavaScript jabber. We did an episode 45 00:02:05.840 --> 00:02:09.759 on micro front ends about three weeks ago. We recorded it. Anyway, 46 00:02:10.199 --> 00:02:12.360 we're a little more ahead on that, so it's probably 47 00:02:12.360 --> 00:02:14.680 going to come out in a few weeks. But it's 48 00:02:14.759 --> 00:02:17.080 just interesting because people are talking about this and how 49 00:02:17.120 --> 00:02:21.280 to break up application logic and stuff like that, and 50 00:02:21.960 --> 00:02:24.240 of course in RAILS we all talked about the beautiful 51 00:02:24.280 --> 00:02:27.319 monolith and you know how that all kind of comes 52 00:02:27.319 --> 00:02:30.400 together to put it all in one app. And so, yeah, 53 00:02:30.560 --> 00:02:32.639 I'm kind of interested because I don't know that I 54 00:02:32.719 --> 00:02:36.680 necessarily got the breakdown on where you come down on this. 55 00:02:36.800 --> 00:02:40.000 And I remember early in my career, like soa service 56 00:02:40.039 --> 00:02:42.639 oriented architecture was a big thing, and I think I 57 00:02:42.680 --> 00:02:44.120 gave a whole bunch of talks and gave a whole 58 00:02:44.120 --> 00:02:46.800 bunch of bad advice because it was the cool thing 59 00:02:46.800 --> 00:02:48.680 to do, and I was really in love with the idea. 60 00:02:49.240 --> 00:02:51.879 But you know, been built a few apps and took 61 00:02:51.879 --> 00:02:54.120 it way too far and it was like, you know 62 00:02:55.120 --> 00:02:57.080 a lot of this stuff really does belong in its 63 00:02:57.080 --> 00:03:00.000 own app, and then some of this stuff it started okay, 64 00:03:00.080 --> 00:03:02.199 some of this stuff belongs in workers and some of 65 00:03:02.199 --> 00:03:04.879 this stuff actually, you know, may belong in its own service, 66 00:03:05.039 --> 00:03:07.280 you know, micro service. And so you know, I kind 67 00:03:07.319 --> 00:03:09.439 of have gone back and forth as to how much 68 00:03:09.560 --> 00:03:13.080 you want to peel off into different parts, and so 69 00:03:13.120 --> 00:03:14.800 I'm kind of curious where you come down as far 70 00:03:14.840 --> 00:03:19.240 as Okay, what do I break off into micro services? 71 00:03:19.319 --> 00:03:22.159 What part do I keep in the monolith? What part 72 00:03:22.240 --> 00:03:25.759 do I you know, and how do I break that up? 73 00:03:25.800 --> 00:03:28.159 And then I also saw some stuff about containerization, so 74 00:03:28.639 --> 00:03:31.439 we can I guess dive into that next. But yeah, 75 00:03:31.479 --> 00:03:33.840 how do how do microft services kind of fit into 76 00:03:33.919 --> 00:03:34.840 Ruby these days? 77 00:03:35.159 --> 00:03:38.319 Yeah? So I think when you're looking at decomposing your 78 00:03:38.319 --> 00:03:41.639 application and doing design, you know, and and and really 79 00:03:42.240 --> 00:03:45.199 there's only one reason that we really do software design, right. 80 00:03:45.719 --> 00:03:47.960 We do it because we're probably going to need to 81 00:03:48.039 --> 00:03:50.479 change our application tomorrow, whether that be to fix some 82 00:03:50.560 --> 00:03:53.319 bugs or to add some new features that people want. 83 00:03:53.879 --> 00:03:57.599 We can't we can't, you know, add patterns and layers 84 00:03:57.639 --> 00:04:01.680 of indirection everywhere. So we need to make choices. I 85 00:04:01.719 --> 00:04:04.599 say that because every time you add a layer of indirection, 86 00:04:05.439 --> 00:04:08.439 there's it's not free. There there's a there's a cost 87 00:04:08.479 --> 00:04:10.479 to it. Right. We can't optimize to be able to 88 00:04:10.599 --> 00:04:15.199 change every aspect of the application. You know. For example, 89 00:04:15.240 --> 00:04:17.279 I've been on a number of projects over my career. 90 00:04:17.879 --> 00:04:19.839 You know, the team would be, well, we need to 91 00:04:19.879 --> 00:04:21.920 abstract this and that so that if we want to 92 00:04:21.959 --> 00:04:25.399 swap out the database later on, we can This is 93 00:04:25.399 --> 00:04:27.680 maybe a little less relevant now, but I think the 94 00:04:27.759 --> 00:04:30.519 example still holds, and so there was effort spin into that. Now, 95 00:04:30.519 --> 00:04:33.680 how many of those projects ever actually swapped out databases? 96 00:04:34.199 --> 00:04:36.680 You know, I can think of maybe one that went 97 00:04:36.720 --> 00:04:39.360 from a relational database to a no sequel, and they 98 00:04:39.399 --> 00:04:42.759 would if they had to make broader changes anyway, So 99 00:04:42.959 --> 00:04:44.839 you need to you need to think about where can 100 00:04:44.879 --> 00:04:49.839 I decompose my logic into reusable bits. And when you 101 00:04:49.879 --> 00:04:55.480 think about the basic rails architecture model view controller, generally speaking, 102 00:04:55.519 --> 00:04:58.800 you try to push that logic down in that if 103 00:04:58.839 --> 00:05:01.040 you think about it as a layer down as far 104 00:05:01.120 --> 00:05:05.000 as you can. You know, validations you'll always need to 105 00:05:05.079 --> 00:05:08.079 do before you persist to the database. Yeah, put it 106 00:05:08.120 --> 00:05:11.959 in the in the model class. But it becomes very 107 00:05:12.040 --> 00:05:14.360 tough when you think about this. You know, there's lots 108 00:05:14.360 --> 00:05:17.519 of best practice and things about where to put quote 109 00:05:17.600 --> 00:05:22.519 unquote business logic, and in my experience that often ends 110 00:05:22.639 --> 00:05:27.480 up coming back to the service level or in rails, 111 00:05:27.519 --> 00:05:31.040 you know the equivalent of a rail's action a controller method. 112 00:05:31.759 --> 00:05:34.920 So if I'm a you want your code to mirror 113 00:05:35.079 --> 00:05:38.240 the real world as closely as possible, and I was 114 00:05:38.439 --> 00:05:42.199 you know, you mentioned earlier. I've probably given bad advice 115 00:05:42.240 --> 00:05:44.160 in my career in the past too. I used to 116 00:05:44.199 --> 00:05:48.800 be huge enthusiast of object oriented and while I think 117 00:05:48.800 --> 00:05:50.800 it's still valuable and has its place, I think in 118 00:05:50.920 --> 00:05:54.319 terms of decomposition, if you want to mirror the real world. 119 00:05:54.399 --> 00:05:59.360 If I'm a customer, I don't think of objects and entities. 120 00:05:59.399 --> 00:06:02.480 So let's say I'm going to go online to pay 121 00:06:02.560 --> 00:06:05.519 my credit card bill. I don't think about that in 122 00:06:05.600 --> 00:06:08.439 terms of, well, there's an account object and a vendor 123 00:06:08.920 --> 00:06:12.120 and a payment behavior. I think about that of I'm 124 00:06:12.120 --> 00:06:14.680 going to go pay my bill. You know, it's it's 125 00:06:14.800 --> 00:06:17.920 an action I take, something I do. And so you 126 00:06:17.920 --> 00:06:20.399 can try to push logic further down this stack, but 127 00:06:20.600 --> 00:06:22.959 usually it ends up kind of bubbling back up to 128 00:06:24.079 --> 00:06:28.639 this service layer because those are encapsulated units of work. 129 00:06:28.959 --> 00:06:33.319 Now paying your paying your bill that now I personally 130 00:06:33.319 --> 00:06:35.360 wouldn't do this, But let's say let's say I was 131 00:06:35.439 --> 00:06:38.759 late on paying my bill, so I'm going to incur 132 00:06:38.839 --> 00:06:43.279 a fee. So that's probably another service to calculate what 133 00:06:43.319 --> 00:06:45.319 the late fee is based on when I submit it. 134 00:06:45.360 --> 00:06:48.439 All of that so you can see you can see 135 00:06:48.439 --> 00:06:52.839 that kind of breakdown, and so reusing those services. And actually, 136 00:06:52.839 --> 00:06:55.399 you know, this almost gets back to like functional programming. 137 00:06:55.439 --> 00:06:57.839 It's funny how things kind of come full circle every 138 00:06:58.480 --> 00:07:01.720 every so often. But to me, the service level is 139 00:07:01.759 --> 00:07:04.480 the easiest way to decompose and be close to how 140 00:07:04.839 --> 00:07:07.120 you mirror the real world. And if you can do that, 141 00:07:07.240 --> 00:07:09.800 if you can model it closer, you're going to be 142 00:07:10.160 --> 00:07:11.560 you're going to be better off in the long run 143 00:07:11.600 --> 00:07:14.959 when you need to make make changes. So now segue 144 00:07:15.000 --> 00:07:19.600 that into micro service because microservice often has the connotation 145 00:07:19.800 --> 00:07:25.199 of being a separate physical deployment. So there's different steps 146 00:07:25.199 --> 00:07:27.680 you can take to migrate this. Right, So you mentioned 147 00:07:27.680 --> 00:07:30.639 the beautiful monolith. I might have tons of code all 148 00:07:30.680 --> 00:07:34.639 sitting there. It's in one deployable one deployable unit. You know, 149 00:07:34.759 --> 00:07:36.920 Rome's not built in a day. I can't do all 150 00:07:36.959 --> 00:07:39.600 of this at once. So you know, one of the 151 00:07:39.720 --> 00:07:42.879 articles I wrote that you reference was really just well, 152 00:07:42.920 --> 00:07:45.600 how do I take that first step? How do I 153 00:07:45.680 --> 00:07:49.639 go from the beautiful modelith to whatever my target architecture is, 154 00:07:49.680 --> 00:07:54.839 whatever your favored decomposition model is. So the beautiful thing. 155 00:07:55.000 --> 00:07:57.000 One really nice thing about rails is I think it 156 00:07:57.040 --> 00:07:59.519 helps you out here. So even in my existing code 157 00:07:59.519 --> 00:08:03.519 base a controller action. Let's say you're using rack as 158 00:08:03.560 --> 00:08:07.800 you're middleware. That controller action is actually a wreck its 159 00:08:07.839 --> 00:08:11.160 own RACK application. So in the rack up file, rather 160 00:08:11.199 --> 00:08:14.600 than just doing rails application new, you can actually just 161 00:08:14.639 --> 00:08:18.959 point it directly to that controller action. So now you 162 00:08:18.959 --> 00:08:21.759 can deploy that as a deployable unit. It's going to 163 00:08:21.800 --> 00:08:24.879 use the same code base, but from a logical standpoint, 164 00:08:24.920 --> 00:08:26.759 I've separated that out from the rest of the system. 165 00:08:26.839 --> 00:08:29.360 I can begin to reason about it more, think about 166 00:08:30.079 --> 00:08:33.440 what changes when, how do I reuse things? And then 167 00:08:33.559 --> 00:08:36.039 just to tease the topic a little bit, just to 168 00:08:36.080 --> 00:08:39.000 throw the container bit out there so it's an easier 169 00:08:39.000 --> 00:08:42.480 migration then to make it a separate deployable unit because 170 00:08:42.480 --> 00:08:45.759 that same image, that same codebase, I'm just going to 171 00:08:45.799 --> 00:08:48.679 have a different rackup file that I use for each 172 00:08:48.679 --> 00:08:51.759 of those. I can deploy those separately, I can scale 173 00:08:51.799 --> 00:08:55.600 them independently, I can observe them. See you know how 174 00:08:55.639 --> 00:08:58.240 they behave If one if the CPU goes off, the 175 00:08:58.320 --> 00:08:59.840 rails on one of them is going to be easier 176 00:08:59.840 --> 00:09:04.360 to identify where the problem was. So you don't get 177 00:09:04.360 --> 00:09:07.799 those kind of advantages until you actually make them true 178 00:09:07.799 --> 00:09:11.159 micro services and you get that observability, but there's a 179 00:09:11.159 --> 00:09:13.360 lot of benefits when you start to go down that road, 180 00:09:13.440 --> 00:09:16.120 and rails I think helps. Rails gives you tools to 181 00:09:16.159 --> 00:09:19.679 help do that incrementally. So that's kind of an overview 182 00:09:19.679 --> 00:09:21.879 of where I'm at. I don't I don't think there's one. 183 00:09:22.399 --> 00:09:25.919 There's certainly not a one size fits all, but to 184 00:09:25.960 --> 00:09:30.159 the extent that you can go with micro services to 185 00:09:30.279 --> 00:09:33.600 break that out from a logical design perspective, and then 186 00:09:33.639 --> 00:09:38.919 the actual deployment get the observability, scalability independence. I think 187 00:09:38.919 --> 00:09:40.480 there's a lot of benefit there. 188 00:09:40.879 --> 00:09:44.639 And so just because I can, I want to push 189 00:09:44.720 --> 00:09:48.519 back just a little bit and just to get some 190 00:09:48.519 --> 00:09:54.919 more clarifications. So when we deploy a now isolated bit 191 00:09:54.960 --> 00:10:00.399 of code as a microservice infrastructure speaking, what is going 192 00:10:00.440 --> 00:10:04.799 to look like as far as the database level is concerned. 193 00:10:05.360 --> 00:10:09.279 Are we going to spin up an additional database so 194 00:10:09.440 --> 00:10:13.000 now we have a whole new database server with a 195 00:10:13.039 --> 00:10:16.120 new database on there, or would we just create a 196 00:10:16.200 --> 00:10:21.519 new database within a server. So if we're running postgrads, 197 00:10:21.559 --> 00:10:24.600 we have one instance of postgrads or a cluster, and 198 00:10:24.639 --> 00:10:27.759 then we have a new database for this micro service 199 00:10:28.200 --> 00:10:31.240 and that microservice only communicates to the one database or 200 00:10:31.279 --> 00:10:35.240 do they all share the same global database. 201 00:10:35.720 --> 00:10:39.000 Yeah, that's a great question, and you're poking at you 202 00:10:39.039 --> 00:10:42.279 know why. You want to obviously think through these things carefully, 203 00:10:42.759 --> 00:10:45.559 but yeah, no, it's a great question. So your your data, 204 00:10:45.600 --> 00:10:48.039 what does your data architecture look like? If you're starting 205 00:10:48.039 --> 00:10:50.919 out with the beautiful monolith, you do likely have that 206 00:10:51.000 --> 00:10:54.919 single transactional database. So to the extent that you can 207 00:10:55.120 --> 00:10:59.279 segregate out by you know which objects, which models or 208 00:10:59.360 --> 00:11:02.960 tables are used by sets of services, You're better off 209 00:11:03.000 --> 00:11:07.080 segregating those and making those their own deployable units. You know, 210 00:11:07.120 --> 00:11:10.399 you're still going to have some potential level of contention 211 00:11:10.519 --> 00:11:13.120 because you've got different apps talking to the same database, 212 00:11:13.799 --> 00:11:16.399 and so you know one could have one could certainly 213 00:11:16.399 --> 00:11:18.559 impact the other. You can still have a noisy neighbor 214 00:11:18.639 --> 00:11:22.799 situation there. But as you migrate over time, if you 215 00:11:22.840 --> 00:11:28.120 can decompose your larger architecture into those discrete topic areas 216 00:11:28.600 --> 00:11:31.679 where you can have different databases, then you get a 217 00:11:31.720 --> 00:11:35.759 cleaner isolation, and that typically takes folks a lot longer 218 00:11:36.039 --> 00:11:38.440 to do. And you can also end up in the 219 00:11:38.480 --> 00:11:41.279 spot well where I need I need data from from 220 00:11:41.320 --> 00:11:44.480 both places, and you can end up getting into performance 221 00:11:44.519 --> 00:11:48.159 issues because you get you know, pretty chatty between these services. 222 00:11:48.240 --> 00:11:50.879 So so it's not it's not with it's not a 223 00:11:50.919 --> 00:11:54.600 panacea for sure, but I think to the extent that 224 00:11:54.679 --> 00:11:58.720 teams can start thinking in that direction and trying to 225 00:11:58.759 --> 00:12:01.320 find those what are the what are the good isolation 226 00:12:01.440 --> 00:12:05.200 boundaries to use? And again there is it's not a 227 00:12:05.240 --> 00:12:08.679 black and white topic, but there's no crystal clear answer, 228 00:12:09.480 --> 00:12:12.120 but I think there's over overall if you look at 229 00:12:12.200 --> 00:12:16.519 how do I make changes right? Because in today's economy, 230 00:12:16.559 --> 00:12:20.120 you know, with the pandemic and people being at home, 231 00:12:20.240 --> 00:12:24.600 like we were already essentially a digital economy, it's almost 232 00:12:24.759 --> 00:12:28.639 entirely that way now. So you know, we're all forced 233 00:12:28.679 --> 00:12:34.000 to innovate so much faster, you know, deploy We were 234 00:12:34.039 --> 00:12:37.720 already deploying continuously, and now we want to do it 235 00:12:37.759 --> 00:12:40.039 even more. So if we don't do it fast enough, 236 00:12:40.519 --> 00:12:43.679 someone else is going to copy our business model, We're 237 00:12:43.720 --> 00:12:46.240 going to we're going to lose lose customers we could have. 238 00:12:46.320 --> 00:12:50.039 So there's so much pressure to get features out there faster, 239 00:12:50.799 --> 00:12:54.440 and so again it's you know, you can't optimize for everything, 240 00:12:54.480 --> 00:12:57.279 but it's thinking about well, what is going to benefit 241 00:12:57.320 --> 00:13:01.080 me to isolate where I may want to be able 242 00:13:01.120 --> 00:13:05.240 to innovate faster move separate from the other aspects of 243 00:13:05.279 --> 00:13:08.360 the code. One problem that and even at Amazon our 244 00:13:08.399 --> 00:13:12.200 teams ran into this, especially some of the bigger services, 245 00:13:12.919 --> 00:13:16.360 where you really want to get a bug fix out 246 00:13:16.440 --> 00:13:18.840 or some feature out. But if you're all in the 247 00:13:18.879 --> 00:13:21.519 same if it's all in the same kitten kaboodle, and 248 00:13:21.559 --> 00:13:23.360 you've got an issue that pops up with one of 249 00:13:23.360 --> 00:13:25.200 the other changes, you got to roll that whole thing 250 00:13:25.279 --> 00:13:28.039 back because at the end of the day, you can't 251 00:13:28.399 --> 00:13:32.039 have impact ongoing impact to your customers. And so that 252 00:13:33.080 --> 00:13:36.519 is something that I think really hurts teams their velocity 253 00:13:37.159 --> 00:13:40.639 when you've got to make sure that these twelve or 254 00:13:40.679 --> 00:13:43.919 twenty or however many features are all working perfectly in 255 00:13:44.000 --> 00:13:46.080 order to get all of them out the door. So 256 00:13:46.200 --> 00:13:49.039 rather than an all or nothing, micro services really help 257 00:13:49.080 --> 00:13:52.679 you there. So you wouldn't isolate everything, but the areas 258 00:13:52.720 --> 00:13:54.639 where you know you're going to have a focus on, 259 00:13:55.399 --> 00:13:58.720 or you can predict, or you already know that are 260 00:13:58.720 --> 00:14:00.879 important to your customers, that's where you may want to 261 00:14:00.919 --> 00:14:01.440 think about it. 262 00:14:01.879 --> 00:14:04.919 So one other thing that I'm wondering about because Dave 263 00:14:05.039 --> 00:14:07.000 was like, well, how do you how do you deal 264 00:14:07.039 --> 00:14:10.840 with you know, the database level. I'm thinking, how do 265 00:14:10.879 --> 00:14:13.840 you figure out like traffic coming in right? I mean, 266 00:14:13.840 --> 00:14:16.759 do you have subdomains, do you have like Varnish or 267 00:14:16.799 --> 00:14:19.519 something on the front that you know figures out this 268 00:14:19.600 --> 00:14:23.159 path means this micro service or do you have them 269 00:14:23.240 --> 00:14:25.480 talk to each other through I've seen like rabbit MQ, 270 00:14:26.399 --> 00:14:29.679 which I've also seen be a headache. I mean, how 271 00:14:29.720 --> 00:14:30.679 do you work all that out? 272 00:14:31.159 --> 00:14:34.440 Yeah, So there's a number of solutions here. I think 273 00:14:34.440 --> 00:14:37.440 one nice way to start is just too And here's 274 00:14:37.480 --> 00:14:40.480 where an abstraction does actually benefit you, because you can 275 00:14:40.559 --> 00:14:43.120 put a facade in front of your service. And so 276 00:14:43.200 --> 00:14:45.759 maybe you start out with just actually just calling inline. 277 00:14:45.799 --> 00:14:49.200 You're just calling the class directly in your same Ruby process. 278 00:14:49.600 --> 00:14:51.840 But that then that positions you so that when you 279 00:14:51.879 --> 00:14:54.320 do move it out to a service, you can swap 280 00:14:54.399 --> 00:14:56.759 that out and it's and it's less of a problem 281 00:14:57.039 --> 00:15:01.000 in terms of the domains I like, I personally like 282 00:15:01.080 --> 00:15:04.360 having the different subdomains part of that. I guess the 283 00:15:04.440 --> 00:15:07.559 product that I work with, Engineer facilitates this pretty nicely, 284 00:15:07.559 --> 00:15:10.320 where each of your apps within the same application just 285 00:15:10.320 --> 00:15:13.759 get different subdomains. But there's obviously different ways that you 286 00:15:13.799 --> 00:15:15.879 can do it, and you don't actually you know, of 287 00:15:15.919 --> 00:15:17.879 course you don't need to split that out because you 288 00:15:17.919 --> 00:15:22.480 could just use different URL paths to accomplish a similar goal. 289 00:15:23.360 --> 00:15:26.840 But having the if you get it into containers and 290 00:15:26.840 --> 00:15:30.159 you can segregate, then you get those benefits of the 291 00:15:30.159 --> 00:15:33.639 physical deployment also. So to me, I would keep I 292 00:15:33.840 --> 00:15:36.159 prefer to try to keep it simple. You you know, 293 00:15:36.399 --> 00:15:39.399 certainly there there's a couple different choices there. I mean 294 00:15:39.440 --> 00:15:43.279 I would probably if you can't avoid putting messaging layers 295 00:15:43.279 --> 00:15:45.960 in between, you know that if you can keep it simple, 296 00:15:46.080 --> 00:15:48.679 rest calls, you're you know, unless you need to do 297 00:15:48.720 --> 00:15:51.919 something different, I'd probably would advocate for that. You know, 298 00:15:52.039 --> 00:15:54.480 keep it as simple as possible, but no simpler. But 299 00:15:54.559 --> 00:15:58.120 there's also other tools and frameworks that help you do that. 300 00:15:58.559 --> 00:16:01.639 I haven't worked with it in detail, AWSS Service Mesh, 301 00:16:01.679 --> 00:16:05.639 which helps you orchestrate all of these micro services. So 302 00:16:05.840 --> 00:16:07.919 there are there are things out there that will that 303 00:16:07.960 --> 00:16:10.879 will help you manage all of this, and probably those 304 00:16:10.879 --> 00:16:13.279 are worth it if you really get into large numbers, 305 00:16:13.559 --> 00:16:16.519 if you really your if your enterprise is you know, 306 00:16:16.639 --> 00:16:19.200 truly bought in and you're and you're going across many 307 00:16:19.200 --> 00:16:22.360 different departments in many different organizations. That's probably when you 308 00:16:22.399 --> 00:16:23.559 when you look at something like that. 309 00:16:23.720 --> 00:16:27.120 But yeah, so kind of where I'm going with the 310 00:16:27.159 --> 00:16:29.639 whole database side of things, because I agree, if you 311 00:16:29.679 --> 00:16:33.000 do have a micro services environment, then you should have 312 00:16:33.960 --> 00:16:37.440 a separate database for each micro service. But the issue 313 00:16:37.519 --> 00:16:40.320 kind of comes into play is when you sort off 314 00:16:40.399 --> 00:16:43.720 with just a few micro services, it's fine, it's easy 315 00:16:43.799 --> 00:16:46.720 to manage, but then when you scale up to one 316 00:16:46.799 --> 00:16:51.639 hundred to one thousand to ten thousand, it becomes less manageable, 317 00:16:52.320 --> 00:16:58.440 and your infrastructure cost also is scaling up fairly. 318 00:16:58.320 --> 00:17:01.840 Past five and I'm getting a headache. 319 00:17:02.600 --> 00:17:05.680 So the issue with that scene is when a micro 320 00:17:05.799 --> 00:17:09.759 service stops becoming a micro service and it becomes a 321 00:17:10.079 --> 00:17:15.440 monolith service to where you have now these twenty different 322 00:17:15.799 --> 00:17:20.400 or forty different micro services that just have grown and 323 00:17:20.440 --> 00:17:25.200 grown and grown, and now you have forty separate, full 324 00:17:25.240 --> 00:17:29.359 fledged Ruby on Rails applications that are so highly coupled 325 00:17:29.359 --> 00:17:32.839 and dependent on each other, that would it had been 326 00:17:32.920 --> 00:17:38.200 better to just have built it into one beautiful, majestic monolith. 327 00:17:38.480 --> 00:17:41.160 Yeah, I'm I think I had a similar reaction that 328 00:17:41.759 --> 00:17:45.319 Chuck had. If we get into the thousands, I'm completely 329 00:17:45.400 --> 00:17:48.200 with you, we've probably gone We've gone off the rails 330 00:17:48.200 --> 00:17:49.599 at that point. 331 00:17:49.720 --> 00:17:52.200 I think that's where Netflix is at. I don't know 332 00:17:52.240 --> 00:17:54.880 how many they have, but I've seen their data map 333 00:17:54.960 --> 00:17:58.079 of their micro services and communications. It looks like a 334 00:17:58.119 --> 00:18:01.680 whole globe of just jumbled spaghetti mess. 335 00:18:02.079 --> 00:18:05.319 I believe that's probably correct. I actually got to work 336 00:18:05.359 --> 00:18:07.440 with them a little bit when I was at AWS. 337 00:18:07.960 --> 00:18:11.400 They also are a bit of a snowflake because no, 338 00:18:11.480 --> 00:18:14.200 I mean, there are very few companies or organizations that 339 00:18:14.279 --> 00:18:19.039 have the amount of resources that they have. Companies like Netflix, 340 00:18:19.599 --> 00:18:22.839 like Amazon, you know, there aren't very many folks that 341 00:18:22.920 --> 00:18:26.880 can put that many resources on it. And they have 342 00:18:26.920 --> 00:18:30.160 a vast amount of capability as well. I think for 343 00:18:30.960 --> 00:18:34.960 small and medium sized business, you're looking at a different 344 00:18:35.000 --> 00:18:39.559 category and a different type of architecture, and it would 345 00:18:39.599 --> 00:18:42.480 probably not be good if you got into those numbers. 346 00:18:43.039 --> 00:18:46.839 I will say, on the infrastructure cost point that you 347 00:18:46.960 --> 00:18:50.119 brought up, I think that would be true on if 348 00:18:50.200 --> 00:18:54.759 you're on instances or virtual machines. However, containers are very 349 00:18:54.839 --> 00:18:58.599 efficient at this You can put a lot more container 350 00:18:58.640 --> 00:19:03.039 processes on the underlying hardware, and you can you also 351 00:19:03.039 --> 00:19:05.720 get a lot of those other benefits that I that 352 00:19:05.799 --> 00:19:09.440 I mentioned. So I don't know that the infrastructure cost 353 00:19:09.480 --> 00:19:11.599 would be quite as bad as you as you think 354 00:19:11.599 --> 00:19:15.920 it is, because the container processes are pretty lightweight. They 355 00:19:16.160 --> 00:19:19.920 can start up in milliseconds as opposed to you know, 356 00:19:20.079 --> 00:19:22.920 like an EC two instance probably takes like between thirty 357 00:19:22.960 --> 00:19:26.240 and sixty seconds to start up, whereas a container, let's 358 00:19:26.279 --> 00:19:29.039 say it, let's round it off to a second. So 359 00:19:29.160 --> 00:19:32.000 you can scale those up and down really really quickly, 360 00:19:32.319 --> 00:19:35.359 and you can pack a lot more onto a physical 361 00:19:35.400 --> 00:19:37.440 cluster as well. So I don't know if that would 362 00:19:37.440 --> 00:19:39.079 be as much of an issue. But on the on 363 00:19:39.160 --> 00:19:43.480 the complexity front, Tim, I agree, there's some point where 364 00:19:43.480 --> 00:19:44.960 it becomes unmanageable. Yeah. 365 00:19:45.160 --> 00:19:48.960 The infrastructure scaling pricing that I was referring to is 366 00:19:49.000 --> 00:19:51.839 more on the database side, because on a small tier 367 00:19:51.920 --> 00:19:56.240 database that's really all the application needs. But because you 368 00:19:56.279 --> 00:19:59.799 have scaled it up to fifty or one hundred micro services, 369 00:20:00.240 --> 00:20:02.359 you're not going to be able to connect to that 370 00:20:02.440 --> 00:20:06.839 same database instance with the lower tier plan because the 371 00:20:06.960 --> 00:20:11.640 number of max connections that's available on those various plans, 372 00:20:11.680 --> 00:20:16.039 you would have to either spin up multiple database servers, 373 00:20:16.480 --> 00:20:21.279 in which case you incur scaling costs there, or have 374 00:20:21.319 --> 00:20:25.559 one really large database server where you have multiple databases 375 00:20:26.279 --> 00:20:29.559 within there, and then you still incur a higher cost 376 00:20:29.960 --> 00:20:33.960 just for that max number of connections. Now, AWS may 377 00:20:34.000 --> 00:20:37.079 have something different now where you can allow more connections, 378 00:20:37.440 --> 00:20:40.519 but each micro service would need at least its one 379 00:20:40.680 --> 00:20:43.839 own dedicated connection to the database instance. 380 00:20:44.359 --> 00:20:47.440 Yeah, unless your databases are of pretty decent size, I 381 00:20:47.480 --> 00:20:50.119 would probably go the route you mentioned where if you're 382 00:20:50.160 --> 00:20:53.079 talking AWS, you have an RDS database and you can 383 00:20:53.079 --> 00:20:57.039 put multiple not instances, multiple schemas on there, right, so 384 00:20:57.039 --> 00:20:59.920 at least you can segregate it that way. You know, 385 00:21:00.200 --> 00:21:03.599 if many many of these micro services, if they have 386 00:21:03.640 --> 00:21:06.480 a smaller footprint, there's not no real reason to have 387 00:21:06.519 --> 00:21:09.519 a different physical instance, you know, you don't need to 388 00:21:09.599 --> 00:21:13.000 take that separation to the n degree. Not to be 389 00:21:13.079 --> 00:21:18.240 too salesy, but we do. The company EngineYard also has 390 00:21:18.519 --> 00:21:21.799 a scale arc product which is a database proxy, which 391 00:21:21.839 --> 00:21:25.160 is also a nice way to actually get the three 392 00:21:25.279 --> 00:21:30.400 tier architecture independence actually separate out your application tier from 393 00:21:30.400 --> 00:21:33.200 your database by connecting to the proxy and then it 394 00:21:33.240 --> 00:21:36.160 can talk to all of these other databases make them 395 00:21:36.160 --> 00:21:39.799 look like different connections, do caching, intelligent caching, and security 396 00:21:39.839 --> 00:21:42.680 controls for you. Again, if you get into larger number 397 00:21:42.680 --> 00:21:46.759 of databases, that might be something that's that's helpful. But yeah, 398 00:21:46.839 --> 00:21:51.400 packing multiple database schemas on the same you know, RDS 399 00:21:51.400 --> 00:21:54.839 cluster is actually pretty pretty good strategy in a lot 400 00:21:54.920 --> 00:21:57.039 of cases unless you have a really high volume er, 401 00:21:57.519 --> 00:21:59.279