Architectures and Microservices with Darren Broemmer - RUBY 657

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
a really large sized database.
402
00:22:00.079 --> 00:22:03.319
Whole container idea instead of the virtual machines I really
403
00:22:03.400 --> 00:22:06.839
do like and I think that especially even if you
404
00:22:06.880 --> 00:22:12.200
stick with a monolith version of your application to do
405
00:22:12.279 --> 00:22:17.400
auto scaling, you can more instantaneously respond to the demand
406
00:22:17.480 --> 00:22:21.480
coming in opposed to provisioning a whole new virtual machine.
407
00:22:21.920 --> 00:22:25.319
So I'm really with you on there with using doctor
408
00:22:25.359 --> 00:22:29.160
containers and stuff like that, because I think that's the
409
00:22:29.319 --> 00:22:34.200
proper way to do auto scaling because you get instant
410
00:22:34.319 --> 00:22:38.279
reaction to your users instead of having to wait, Okay,
411
00:22:38.359 --> 00:22:42.319
we're at a fifty percent usage load across all our vms.
412
00:22:42.599 --> 00:22:46.279
We need to hurry up and add more servers, all automatically,
413
00:22:46.319 --> 00:22:50.559
of course, But then fifteen minutes later the server's provision
414
00:22:50.839 --> 00:22:54.839
and now it's ready. Well, that traffic's all said and done.
415
00:22:54.720 --> 00:22:59.759
Now absolutely, so yeah, these those two things that we've
416
00:22:59.759 --> 00:23:02.440
been talking about, the micro services and the containers are
417
00:23:02.519 --> 00:23:06.400
most certainly independent. So like you were just saying, even
418
00:23:06.880 --> 00:23:10.160
with beautiful monolith, containers give you a lot of benefit.
419
00:23:10.200 --> 00:23:12.640
They give you this scale, really fast scalability that you
420
00:23:12.720 --> 00:23:15.640
just talked about, and something we haven't even mentioned yet,
421
00:23:15.680 --> 00:23:19.680
it's actually pretty nice for development as well. So developing
422
00:23:20.440 --> 00:23:25.160
with containers really helps cut down on how many times,
423
00:23:25.200 --> 00:23:27.920
how much time in my career have I spent getting
424
00:23:27.960 --> 00:23:32.039
my workstation, my development environment set up the way that
425
00:23:32.079 --> 00:23:35.240
I want it, and you know, managing those things. So
426
00:23:35.640 --> 00:23:39.240
using containers for development is really nice for that. There's
427
00:23:39.279 --> 00:23:42.359
also some really nice tooling to help out there as well,
428
00:23:42.480 --> 00:23:46.759
so we offer dev spaces. There's also an open source
429
00:23:46.920 --> 00:23:51.319
gipod where you can with a single click bring up
430
00:23:51.359 --> 00:23:55.599
the online ide. It's running based on the container that
431
00:23:55.680 --> 00:23:58.480
you define, and you can also do some simple automation,
432
00:23:58.640 --> 00:24:01.960
so for example, you can have it on startup, do
433
00:24:02.039 --> 00:24:06.079
your bundle, install, start your rail server. It opens up
434
00:24:06.119 --> 00:24:11.480
a preview window inside of your online ide, which is
435
00:24:11.559 --> 00:24:16.559
based roughly it's based roughly on vs code, so you
436
00:24:16.599 --> 00:24:19.440
can use those extensions as well, so, yeah, so you
437
00:24:19.480 --> 00:24:22.880
get benefits from containers, not just in the deployment, but
438
00:24:22.920 --> 00:24:26.160
I think in the development as well, and you know,
439
00:24:26.200 --> 00:24:29.279
hopefully never have to hear the phrase works on my machine. Again.
440
00:24:29.799 --> 00:24:33.119
That helps to alleviate some of those issues.
441
00:24:33.119 --> 00:24:36.240
Until you get half the developers using ARM the other
442
00:24:36.279 --> 00:24:39.480
half using xAd six platforms.
443
00:24:41.559 --> 00:24:44.720
Yes, there's a whole another paradigm shift that we now
444
00:24:44.759 --> 00:24:49.640
have to think about, right, Well, I know, yeah, I
445
00:24:49.640 --> 00:24:52.319
know a lot of the Ruby gems do work on it,
446
00:24:52.319 --> 00:24:55.519
but there's a handful that don't. And I know the
447
00:24:55.559 --> 00:24:59.400
company I work with as actually we're investing actually looking
448
00:24:59.440 --> 00:25:02.720
for rubis to help make get all of those gems
449
00:25:02.799 --> 00:25:06.279
up to speed un armed because the price improvement, sorry,
450
00:25:06.279 --> 00:25:10.920
the performance and price improvement is really significant. So it's
451
00:25:11.000 --> 00:25:12.200
a it's a big boost.
452
00:25:13.079 --> 00:25:15.680
Yeah, I couldn't have said it better myself. I have
453
00:25:15.839 --> 00:25:18.599
a eight core mac Pro one hundred and ninety two
454
00:25:18.599 --> 00:25:22.720
gigs RAM thing is a monster. Then I have a
455
00:25:23.119 --> 00:25:28.000
thirteen inch MacBook PROILM one with sixteen gigs of RAM.
456
00:25:28.400 --> 00:25:31.640
You know, whatever it comes with. I can't tell a
457
00:25:31.680 --> 00:25:35.119
difference in performance on my day to day tasks. I
458
00:25:35.200 --> 00:25:39.400
really cannot tell the difference. There is a huge price
459
00:25:39.480 --> 00:25:44.039
tag difference. It's insane. So the ELM one, the whole
460
00:25:44.200 --> 00:25:48.839
ARM movement that Apple is doing, I think is amazing,
461
00:25:49.319 --> 00:25:53.640
and if they can keep it cost effective, then it's
462
00:25:53.720 --> 00:25:57.039
going to really make a huge difference in how we
463
00:25:57.119 --> 00:25:59.839
approach things, no.
464
00:26:00.359 --> 00:26:04.079
Doubt, one hundred percent agree. I really you know now
465
00:26:04.119 --> 00:26:08.359
that I'm a developer evangelist. I shifted from engineer too.
466
00:26:08.400 --> 00:26:10.240
I guess you could say I'm on the marketing side,
467
00:26:10.279 --> 00:26:15.680
so still an engineer at heart. But the phrase game
468
00:26:15.759 --> 00:26:19.279
changer gets overused so many times. When you go to conferences,
469
00:26:19.279 --> 00:26:21.880
you hear this is a game changer, that's a game changer.
470
00:26:22.440 --> 00:26:25.720
I think. I think the use of ARM, what we're
471
00:26:25.759 --> 00:26:28.440
talking about here, I think actually does fall into that category.
472
00:26:28.480 --> 00:26:30.000
I think it's a big shift and you're going to
473
00:26:30.000 --> 00:26:33.079
see a lot of energy put toward that, and I
474
00:26:33.079 --> 00:26:35.440
think it's really going to help things out. I mean,
475
00:26:35.960 --> 00:26:39.799
people complain about sometimes rails being slow. It's like, well,
476
00:26:40.400 --> 00:26:42.240
if you run it on a faster computer, that that's
477
00:26:42.279 --> 00:26:45.319
a really nice way to solve that problem. Certainly certainly
478
00:26:45.359 --> 00:26:48.119
cost effective there, it's a lot cheaper than the person
479
00:26:48.160 --> 00:26:51.839
hours that you might spend diving in, diving into that potentially.
480
00:26:53.079 --> 00:26:55.559
Yeah, I want to move us back toward micro service
481
00:26:55.599 --> 00:26:59.119
here services here for a minute, because I just remember
482
00:26:59.160 --> 00:27:02.400
the nightmares. I went, you're moving stuff to micro services
483
00:27:02.400 --> 00:27:04.799
back in the day, and I can kind of imagine
484
00:27:04.839 --> 00:27:07.960
scenarios that are somewhat obvious, right, I mean, you know,
485
00:27:08.000 --> 00:27:12.079
you can move your authorization right over to micro services
486
00:27:12.079 --> 00:27:15.119
and then you just you know, maybe do some permissions
487
00:27:15.200 --> 00:27:19.839
checks or you know, authority checks validate that somebody's actually
488
00:27:19.880 --> 00:27:21.880
who they say they are against their identity on the
489
00:27:21.920 --> 00:27:24.839
machine or on the other service, right, And so that's
490
00:27:24.920 --> 00:27:28.960
kind of an obvious one to me. But I remember
491
00:27:29.000 --> 00:27:31.640
we tried to split our app up into services, and
492
00:27:31.680 --> 00:27:35.519
things were pretty tightly coupled together. And it's because the
493
00:27:35.599 --> 00:27:38.920
concerns kind of blended from one thing to the next,
494
00:27:39.000 --> 00:27:40.799
right from one step to the next or stage to
495
00:27:40.839 --> 00:27:43.519
the next, as things move through the system, and so
496
00:27:43.599 --> 00:27:46.839
there really wasn't a clear cut, a clear place to cut.
497
00:27:47.000 --> 00:27:49.359
And so we when we picked one because it's like, oh, well,
498
00:27:49.400 --> 00:27:51.640
this is stage one and this is stage two, so
499
00:27:51.680 --> 00:27:53.720
we're just going to cut it between stage one and
500
00:27:53.720 --> 00:27:56.200
stage two. Well it turned out that stage one and
501
00:27:56.240 --> 00:27:58.240
stage two still have a lot in common, and so
502
00:27:59.079 --> 00:28:01.559
you know, there's not that clear delineation, and so it
503
00:28:01.599 --> 00:28:04.480
gave us problems. And you know, I'm thinking about some
504
00:28:04.559 --> 00:28:06.319
of the apps that I'm working on now and a
505
00:28:06.359 --> 00:28:08.279
lot of them have that same problem. And that's why
506
00:28:08.319 --> 00:28:13.240
this monolith idea works really nicely, right, is because all
507
00:28:13.279 --> 00:28:16.319
of those concerns that kind of span the entire app
508
00:28:16.839 --> 00:28:20.000
are all in there. So how do you start to
509
00:28:20.039 --> 00:28:24.200
really think about Okay, you know this is a good
510
00:28:24.440 --> 00:28:28.440
option for a micro service, and this maybe does belong
511
00:28:28.480 --> 00:28:29.240
in a monolith.
512
00:28:29.400 --> 00:28:32.559
Yeah, it's a great question. So you know, I mentioned
513
00:28:32.920 --> 00:28:36.400
that earlier. I wrote a book with the phrase best
514
00:28:36.400 --> 00:28:38.200
practices and a title, and I think I have a
515
00:28:38.200 --> 00:28:41.960
little bit different take on that now. I believe that
516
00:28:42.200 --> 00:28:44.400
the use of micro services what we've been talking about,
517
00:28:44.480 --> 00:28:46.400
is a great practice to do if it works for you,
518
00:28:47.200 --> 00:28:51.599
and it's probably you know, it's not a one one
519
00:28:51.640 --> 00:28:56.240
size fits all, So it's more of a concept that
520
00:28:56.279 --> 00:28:58.920
you can apply to your situation. If it's really hard
521
00:28:58.960 --> 00:29:04.279
to to untangle those concerns, you know, maybe maybe you
522
00:29:04.839 --> 00:29:07.599
just keep it in, keep it in that single app.
523
00:29:07.680 --> 00:29:11.359
Maybe it's not not worth doing, not worth the effort
524
00:29:11.440 --> 00:29:12.680
to break it out.
525
00:29:12.880 --> 00:29:16.480
So I basically have a general rule of thumb when
526
00:29:16.519 --> 00:29:21.480
it comes to micro services if this feature, you know.
527
00:29:21.839 --> 00:29:24.759
So let's give a real world example. Let's say if
528
00:29:24.920 --> 00:29:29.680
I'm in the business of PDFs and whether I'm a
529
00:29:29.839 --> 00:29:34.720
government or whomever, and I want to have the ability
530
00:29:35.200 --> 00:29:39.519
to take in a PDF and then have it automatically
531
00:29:40.119 --> 00:29:43.440
do the form fill out based on the parameters that
532
00:29:43.519 --> 00:29:48.599
are coming in. So this is a very useful feature
533
00:29:49.039 --> 00:29:52.039
for one of the applications that I'm developing within our
534
00:29:52.079 --> 00:29:56.839
same organization. This feature is also very useful for five
535
00:29:56.880 --> 00:30:02.440
other applications that we're developing. So because this feature can
536
00:30:02.839 --> 00:30:07.599
provide a lot of usefulness to these five different applications,
537
00:30:08.279 --> 00:30:11.640
and we can come to some kind of compromis or
538
00:30:11.759 --> 00:30:15.200
agreement on its API of how it should look. It
539
00:30:15.240 --> 00:30:19.400
should be taken a form post with a list of parameters.
540
00:30:19.720 --> 00:30:23.920
It should have an idea of a PDF that is
541
00:30:24.519 --> 00:30:29.759
stored on the database or wherever it's stored. Then we
542
00:30:29.839 --> 00:30:34.720
can have one codebase that serves five applications. So I
543
00:30:34.720 --> 00:30:37.640
think that's a good use case of a micro service.
544
00:30:37.920 --> 00:30:41.079
It does one thing, it does it really well, and
545
00:30:41.160 --> 00:30:44.640
it is highly reusable, not only in my application, but
546
00:30:44.759 --> 00:30:47.079
in multiple other applications.
547
00:30:47.319 --> 00:30:51.240
Yeah, that's a great example. And I think that if
548
00:30:51.279 --> 00:30:55.079
you've identified that as a needs used in more than
549
00:30:55.119 --> 00:30:57.640
three places, which is a good general rule for reuse,
550
00:30:57.680 --> 00:30:59.880
so you know you want to package that up and
551
00:31:00.759 --> 00:31:04.839
not repeat yourself across that group. So how do you
552
00:31:04.880 --> 00:31:07.759
deliver that capability to the other users of it or
553
00:31:07.759 --> 00:31:10.720
even reuse it yourself? And so you know, you could
554
00:31:10.799 --> 00:31:14.119
just point point the other teams or the other developers
555
00:31:14.160 --> 00:31:18.039
to the repo. You could build a gem package it
556
00:31:18.039 --> 00:31:19.880
that way, which is also a nice way to do it,
557
00:31:20.519 --> 00:31:22.559
or the route that you described. You could make it
558
00:31:22.880 --> 00:31:25.160
an API or a micro service and it is it's
559
00:31:25.200 --> 00:31:28.559
well defined and it is that that's a perfect use
560
00:31:28.599 --> 00:31:32.720
case for a micro service, I will say, Chuck, you
561
00:31:32.720 --> 00:31:35.920
also brought up the authorization. So those kind of you know,
562
00:31:36.039 --> 00:31:40.160
non functional concerns are prime candidates as well. They're easy
563
00:31:40.200 --> 00:31:43.440
to separate out from the rest of your application. It's
564
00:31:43.440 --> 00:31:46.799
where you get into the nitty gritty of the business
565
00:31:46.799 --> 00:31:49.160
logic or workflow where it becomes a little bit harder
566
00:31:49.160 --> 00:31:51.960
to do it. I will say, though, to try to
567
00:31:52.000 --> 00:31:55.799
tie some of these threads together. You mentioned earlier Dave
568
00:31:55.920 --> 00:32:01.680
that Netflix has thousands of these and really Aws does too.
569
00:32:01.759 --> 00:32:05.000
So one thing I realized that when I was there.
570
00:32:05.640 --> 00:32:08.759
You know, one of the best things that Amazon does
571
00:32:09.119 --> 00:32:12.720
is they make each team be essentially like its own
572
00:32:12.759 --> 00:32:16.240
startup company, so that that team can innovate as fast
573
00:32:16.279 --> 00:32:19.960
as they can and deliver value to customers. And then
574
00:32:20.039 --> 00:32:22.279
I also say, the worst thing that they do is
575
00:32:22.519 --> 00:32:25.559
that very same thing, because you have all of these
576
00:32:25.599 --> 00:32:29.160
teams not always marching to the same beat and kind
577
00:32:29.200 --> 00:32:32.559
of repeating some things are not always always going in
578
00:32:32.599 --> 00:32:37.559
the same direction, but all of these different web services are.
579
00:32:38.000 --> 00:32:42.359
It's not really Customers think about it as one infrastructure
580
00:32:42.680 --> 00:32:45.680
or platform that they're using, but it's really one hundred
581
00:32:45.680 --> 00:32:48.640
and fifty different services. I think the numbers actually higher
582
00:32:48.759 --> 00:32:53.279
probably now. And so when you're building one of those,
583
00:32:53.440 --> 00:32:57.880
you're using easily, you know, ten or twelve other ones
584
00:32:58.440 --> 00:33:01.160
in order to compose your application. So I worked on
585
00:33:01.200 --> 00:33:06.079
a security service. I helped build Resource Access Manager, and
586
00:33:06.160 --> 00:33:10.799
so you know, in terms of like monitoring and other
587
00:33:11.279 --> 00:33:13.359
kind of things, you know, we obviously we don't. We
588
00:33:13.400 --> 00:33:16.079
didn't build our own monitoring service. We use cloud watch
589
00:33:16.119 --> 00:33:20.720
for example, and authorization of course we use. We used
590
00:33:20.759 --> 00:33:25.319
I am identity access manager. So it's really those are
591
00:33:25.400 --> 00:33:30.559
good examples of large sets of services. You can think
592
00:33:30.599 --> 00:33:33.039
of them as micro services. Some are more coarse grained,
593
00:33:33.720 --> 00:33:36.720
but in order to build up these really large, really
594
00:33:36.799 --> 00:33:40.839
large platforms that can do amazing things that run run
595
00:33:40.839 --> 00:33:43.839
a majority of the Internet when you think about it,
596
00:33:43.880 --> 00:33:46.920
and so there's there's a lot of capability there. Again,
597
00:33:46.960 --> 00:33:49.039
it comes with the caveat Like we talked about before,
598
00:33:49.160 --> 00:33:53.200
those type of companies have, you know, armies of engineers
599
00:33:53.240 --> 00:33:55.240
who can work on all of these things. Most of
600
00:33:55.319 --> 00:33:58.119
us are not in a position where we have that
601
00:33:58.200 --> 00:34:00.319
many other teammates and teams to help us do this.
602
00:34:00.519 --> 00:34:03.240
So you kind of have to right size these design
603
00:34:03.279 --> 00:34:07.680
principles for the scenario, your scenario you're working on. But yeah,
604
00:34:07.759 --> 00:34:09.880
there is no one right answer. You always want to
605
00:34:10.320 --> 00:34:13.239
apply it to your situation.
606
00:34:13.920 --> 00:34:14.320
I guess.
607
00:34:14.400 --> 00:34:17.320
The other the other end of that right is how
608
00:34:17.360 --> 00:34:19.760
big does it have to be to warrant putting it
609
00:34:19.800 --> 00:34:23.400
into a micro service as opposed to putting it into
610
00:34:23.559 --> 00:34:28.480
a delayed job sidekick rescue worker, or just sticking it
611
00:34:28.519 --> 00:34:33.239
in like lib or app services or whatever, as just
612
00:34:33.320 --> 00:34:36.199
the library that just does a thing right and then
613
00:34:36.280 --> 00:34:37.719
just gets called out somewhere.
614
00:34:38.800 --> 00:34:41.920
Yeah, I would, So here's where we get into. I
615
00:34:41.920 --> 00:34:47.159
would evaluate the deployment or sorry, the operational aspect of
616
00:34:47.199 --> 00:34:49.360
it and see what you can get there. So, if
617
00:34:49.360 --> 00:34:52.920
it's a sidekick job, you're going to have a little
618
00:34:53.119 --> 00:34:54.800
less You have to make sure you build in the
619
00:34:54.840 --> 00:34:57.280
metrics and the visibility to see how that is behaving.
620
00:34:58.480 --> 00:35:01.239
If it's its own micro service, which you can, let's
621
00:35:01.239 --> 00:35:03.639
say it's in a container, I can observe that independently
622
00:35:03.800 --> 00:35:07.760
very easily. I can scale it separate from everything else.
623
00:35:08.280 --> 00:35:10.920
So if you let's say you have your web app
624
00:35:10.920 --> 00:35:14.719
and a sidekick process, so you're taking orders on the
625
00:35:15.119 --> 00:35:18.920
front end and Sidekick is doing some fulfillment on the
626
00:35:18.960 --> 00:35:21.639
back end. So if you make a change and let's
627
00:35:21.639 --> 00:35:25.119
say that the CPU spikes or you identify a memory
628
00:35:25.199 --> 00:35:27.840
leak or some other problem, you know it's not going
629
00:35:27.880 --> 00:35:30.039
to be immediately obvious. Well, was that one of the
630
00:35:30.119 --> 00:35:31.760
changes I went into the web app or was it
631
00:35:31.840 --> 00:35:35.320
the asynchronous job, And then what's the impact of that?
632
00:35:35.360 --> 00:35:38.119
The impact is much different, right because your focus, you
633
00:35:38.119 --> 00:35:40.880
should have a relentless focus on your customer. So if
634
00:35:40.920 --> 00:35:43.199
it's the web app, they can't take any orders. If
635
00:35:43.199 --> 00:35:45.960
it's the sidekick process. It's like, well, that's a little
636
00:35:45.960 --> 00:35:48.400
bit better. I can still accept orders and I'm going
637
00:35:48.440 --> 00:35:50.000
to hopefully get that business. I might just be a
638
00:35:50.039 --> 00:35:52.760
little delayed in getting the shipments out or processing whatever,
639
00:35:53.199 --> 00:35:56.679
whatever it is. So having to be its own if
640
00:35:56.719 --> 00:35:59.320
it's valuable like that, right, If I can get benefit
641
00:35:59.360 --> 00:36:03.039
from observing it and scaling it separately, then you're in
642
00:36:03.079 --> 00:36:05.559
a better spot. If you need to scale up that
643
00:36:06.079 --> 00:36:09.079
back end process, if it's doing more work, then you know,
644
00:36:09.119 --> 00:36:11.880
maybe it's nice to have it in a separate deployable unit.
645
00:36:12.360 --> 00:36:14.280
But those are the types of considerations that I would
646
00:36:14.280 --> 00:36:16.880
look at as opposed to, or in addition to, I
647
00:36:16.880 --> 00:36:20.039
should say, the separation of concerns and how easily how
648
00:36:20.079 --> 00:36:22.519
easy is it for me to make code changes if
649
00:36:22.519 --> 00:36:24.639
I need to innovate AD capabilities.
650
00:36:25.880 --> 00:36:29.320
Yeah, so I have a little story that I'll try
651
00:36:29.360 --> 00:36:32.599
to make tangible to this. So I've had a number
652
00:36:32.599 --> 00:36:36.800
of dogs growing up, and one of the dogs, you know,
653
00:36:37.079 --> 00:36:39.960
was a border collie. So the nature of the border
654
00:36:40.000 --> 00:36:44.039
collie is a hurting animal. And if we had installed
655
00:36:44.039 --> 00:36:47.920
an invisible fence around our yard, it really would have
656
00:36:47.960 --> 00:36:51.039
confused the dog because that dog is meant to be
657
00:36:51.079 --> 00:36:55.280
more free, and it would have hurt its nature essentially.
658
00:36:55.880 --> 00:36:59.320
So we got a chain link fence which was a physical,
659
00:36:59.559 --> 00:37:04.519
visible boundary around the yard. And I had another dog
660
00:37:05.159 --> 00:37:08.320
whom was not a hurting dog. They're more of a
661
00:37:08.360 --> 00:37:12.280
guard dog. So that dog wanted to be around me
662
00:37:12.519 --> 00:37:16.320
all the time. It was a rot Wilder Doberman mix
663
00:37:16.800 --> 00:37:19.920
which I named her Kitty, but that's a different story.
664
00:37:22.519 --> 00:37:25.880
And I could let that dog out of the yard,
665
00:37:26.360 --> 00:37:29.159
you know, into a open backyard and run free, and
666
00:37:29.199 --> 00:37:31.840
we never had to worry about her because she always
667
00:37:31.880 --> 00:37:34.360
quickly came right back to us because she wanted to
668
00:37:34.360 --> 00:37:37.480
be right there next to us. She wasn't interested in
669
00:37:37.559 --> 00:37:42.079
hunting or hurting. So the idea of in translating this
670
00:37:42.239 --> 00:37:45.159
back over to what we're talking about with micro services
671
00:37:45.400 --> 00:37:49.559
versus monoliths, I think that the monolith is more like
672
00:37:49.599 --> 00:37:54.440
that big open backyard without any boundaries. And if you're
673
00:37:54.519 --> 00:37:58.119
not careful, it's not a matter of if, but just
674
00:37:58.159 --> 00:38:01.159
a matter of when are you going to to have
675
00:38:01.360 --> 00:38:05.400
an accident or mistake on your hands because you have
676
00:38:06.280 --> 00:38:10.480
now gotten too much cross contamination within your application. You
677
00:38:10.519 --> 00:38:14.280
weren't careful with the boundaries and you broke a lot
678
00:38:14.320 --> 00:38:20.000
of single responsibility principles, and now things are too tightly
679
00:38:20.119 --> 00:38:23.400
coupled and intertwined in together, and you have a mess.
680
00:38:23.679 --> 00:38:27.440
Whereas the fenced in backyard is more like the micro services,
681
00:38:27.480 --> 00:38:31.880
where you are forced to stay within this confined area,
682
00:38:32.320 --> 00:38:37.239
which means you're forced to think about and write the
683
00:38:37.400 --> 00:38:42.960
single responsibility principles because you don't have access to the
684
00:38:43.000 --> 00:38:47.679
outside world beyond your gated fens. And I think that
685
00:38:48.320 --> 00:38:52.280
if we are talking about a single application, that its
686
00:38:52.320 --> 00:38:57.480
codebase is never reused anywhere else. So I think that
687
00:38:57.960 --> 00:39:03.599
we can train ourselves as developers to have more responsibility
688
00:39:03.719 --> 00:39:07.440
in how we are writing our code, to not introduce
689
00:39:07.559 --> 00:39:13.400
a lot of this cross contamination of logic which really
690
00:39:13.400 --> 00:39:17.639
should be separated out. And by doing that, like Chuck said,
691
00:39:17.719 --> 00:39:21.760
with the lib or app services or interactors, whatever kind
692
00:39:21.760 --> 00:39:24.320
of naming you want to call it, but these plain
693
00:39:24.400 --> 00:39:28.960
old Ruby objects where you're encapsulating and building these virtual
694
00:39:29.119 --> 00:39:32.920
fences around that bit of logic, then you're able to
695
00:39:33.440 --> 00:39:38.159
create the idea of the micro services without breaking up
696
00:39:38.199 --> 00:39:39.719
the majestic monolith.
697
00:39:40.199 --> 00:39:43.199
That's a great analogy for separation of concerns. I got
698
00:39:43.199 --> 00:39:45.719
to remember that one and use that in the future.
699
00:39:46.480 --> 00:39:49.800
The dogs in the fenced in backyard. I like that. Yep, yeah,
700
00:39:49.840 --> 00:39:53.039
I mean I think that you brought up a really
701
00:39:53.039 --> 00:39:56.199
good point. It's like, well, you know, we're all if
702
00:39:56.199 --> 00:39:58.960
we're all in the same backyard, you know, how long
703
00:39:59.000 --> 00:40:02.639
will it be until we all you know, cause problems
704
00:40:02.679 --> 00:40:04.719
We bump into each other trying to get our work done.
705
00:40:05.559 --> 00:40:07.239
You know, one person is cutting the grass in the
706
00:40:07.280 --> 00:40:09.320
backyard while the others are trying to play volleyball. It
707
00:40:09.440 --> 00:40:14.320
just doesn't work very well. And so, you know, we
708
00:40:14.639 --> 00:40:17.159
talked about actually like as it gets bigger, it can
709
00:40:17.199 --> 00:40:19.280
get more complicated. But you can look at it the
710
00:40:19.320 --> 00:40:21.960
other way that as you know, it's easy when you're
711
00:40:21.960 --> 00:40:24.519
getting started to have it all being you know, app
712
00:40:24.559 --> 00:40:26.760
and live, it's actually as you get bigger and bigger
713
00:40:26.800 --> 00:40:31.079
where it becomes more of a challenge because changing one
714
00:40:31.119 --> 00:40:36.320
thing has ramifications and unintended places, and that's really one
715
00:40:36.400 --> 00:40:39.679
of the one of the big challenges. There's a pretty
716
00:40:39.760 --> 00:40:43.039
nice tool that I've been working with or testing out
717
00:40:43.159 --> 00:40:47.800
called app land and its it's a it's open source,
718
00:40:47.840 --> 00:40:49.760
you can grab it and it gives you a nice
719
00:40:49.880 --> 00:40:53.679
visual map of the connections the call stacks and you
720
00:40:53.719 --> 00:40:56.679
can see how your components are related. You know, I
721
00:40:56.679 --> 00:40:59.800
always like to see I'd like to have a visual
722
00:41:00.199 --> 00:41:03.719
or mental model in my head of their requests coming
723
00:41:03.760 --> 00:41:06.639
in and how the route that they take through the
724
00:41:06.679 --> 00:41:09.360
controller and what objects they actually use. And this gives
725
00:41:09.400 --> 00:41:12.719
you a nice kind of visual representation of that. This
726
00:41:12.840 --> 00:41:15.400
was actually something that I thought about when you know,
727
00:41:15.440 --> 00:41:18.760
I first started doing Rails and Ruby, which I mentioned,
728
00:41:18.760 --> 00:41:21.880
you know, like six seven years ago. And when you
729
00:41:21.920 --> 00:41:24.039
do Ruby or sorry when you excuse me, when you
730
00:41:24.079 --> 00:41:28.360
do rails new it's interesting you actually get I think
731
00:41:28.400 --> 00:41:32.760
it's about fifty files with five hundred lines of code,
732
00:41:33.360 --> 00:41:36.159
give or take. And Rails isn't embarrassed about this either,
733
00:41:36.199 --> 00:41:39.119
because you can do bin rail stats and it'll tell
734
00:41:39.119 --> 00:41:42.320
you exactly how many files and lines of code there are.
735
00:41:43.079 --> 00:41:45.960
So that's a lot of code and a lot of
736
00:41:46.000 --> 00:41:48.519
files just to do a Hello World. Right. If I
737
00:41:48.559 --> 00:41:50.880
was going to compare that to no JS, for example,
738
00:41:51.400 --> 00:41:54.639
I think probably one file maybe what like five lines
739
00:41:54.679 --> 00:41:59.039
something like that. But that's there's also the positive aspect
740
00:41:59.079 --> 00:42:01.440
of it that it gives me. It prescribes a lot
741
00:42:01.440 --> 00:42:03.400
of things for me. I always if I know, if
742
00:42:03.440 --> 00:42:06.199
I want to find out where a controller action is.
743
00:42:06.239 --> 00:42:07.960
I know exactly where to look. If I want to
744
00:42:08.000 --> 00:42:11.360
find where the images are located, I already know. So
745
00:42:11.400 --> 00:42:15.239
it gives me a great framework to get started. It doesn't,
746
00:42:15.400 --> 00:42:18.760
you know, it's not going to stop you from dumping,
747
00:42:19.000 --> 00:42:22.199
from making your your helper's directory become a dumping ground
748
00:42:22.239 --> 00:42:26.760
for every everything known to man and having all kinds
749
00:42:26.800 --> 00:42:28.760
of all kinds of stuff in there. That's not going
750
00:42:28.840 --> 00:42:31.039
to prevent that. And that's where the backyard can get
751
00:42:31.800 --> 00:42:35.000
kind of messy. I will say the one having worked
752
00:42:35.039 --> 00:42:38.679
on a lot of different projects in different languages and technologies,
753
00:42:38.679 --> 00:42:40.880
it's nice, you know. It used to be that on
754
00:42:40.920 --> 00:42:44.440
every project you would have the infamous like string helper class,
755
00:42:45.079 --> 00:42:46.920
and so it's nice that we don't have to do
756
00:42:46.960 --> 00:42:49.760
that in Ruby because the string the string class is
757
00:42:49.800 --> 00:42:52.760
pretty rich and as most of what you need, so
758
00:42:53.440 --> 00:42:54.880
we don't we don't have to do with that. But
759
00:42:55.360 --> 00:42:58.039
you know, helper directories always things like that can get
760
00:42:58.440 --> 00:43:01.239
messy pretty quickly if you're not careful. My daughter has
761
00:43:01.239 --> 00:43:05.360
a multiese poodle, Peanut, and I'm pretty sure when I
762
00:43:05.400 --> 00:43:07.119
take Peanut out for a walk, if I took him
763
00:43:07.119 --> 00:43:09.440
off the leash. I'm pretty sure he would go running.
764
00:43:09.480 --> 00:43:12.320
I don't think he's the guard dog that that would
765
00:43:12.320 --> 00:43:14.800
stand by my side. He'd be you know, like down
766
00:43:14.880 --> 00:43:17.199
the road checking things out. That he's probably like, finally
767
00:43:17.199 --> 00:43:18.639
I get to go run around.
768
00:43:19.599 --> 00:43:21.360
Yeah. That's funny because when I was a kid, we
769
00:43:21.440 --> 00:43:22.159
had two dogs.
770
00:43:22.760 --> 00:43:25.119
We had a cocker Spaniel and you know, so she
771
00:43:25.199 --> 00:43:26.559
was kind of a little dog, and then we had
772
00:43:26.559 --> 00:43:29.800
a miniature Chihuahua and she was a littler dog, a
773
00:43:29.880 --> 00:43:31.920
much littler dog. She weighed about a pound and a half.
774
00:43:32.400 --> 00:43:36.480
Oh wow, Yeah, she was tiny, and we the cocker
775
00:43:36.480 --> 00:43:39.239
spaniel couldn't get out of the backyard, but she could
776
00:43:39.280 --> 00:43:41.719
dig holes deep enough for the chihuaha to get out
777
00:43:41.719 --> 00:43:43.159
of the backyard. And there was nothing we could do
778
00:43:43.199 --> 00:43:46.760
to stop it. And so and that, I guess taking
779
00:43:46.760 --> 00:43:48.920
that metaphor to the next level. That's the other thing
780
00:43:48.920 --> 00:43:51.920
that you find is if everybody, if you share the backyard,
781
00:43:52.159 --> 00:43:53.840
somebody's going to find a way to dig a hole
782
00:43:53.920 --> 00:43:54.920
to let people out.
783
00:43:55.719 --> 00:44:01.599
That's a great point. So years will always find a way.
784
00:44:02.280 --> 00:44:04.079
So now we're in a Jurassic Park.
785
00:44:04.559 --> 00:44:11.559
But anyway, Yeah, it's it's definitely interesting to think about
786
00:44:11.599 --> 00:44:14.119
But at the end of the day, I mean, we're
787
00:44:14.159 --> 00:44:17.280
we're just trying to solve problems, right. And it's it's
788
00:44:17.320 --> 00:44:19.760
interesting too because I keep having the conversation with my
789
00:44:19.840 --> 00:44:23.199
coworkers and it's you know, I shouldn't suggest this because
790
00:44:23.199 --> 00:44:25.280
this is work that I don't want to have to do,
791
00:44:26.039 --> 00:44:28.280
but this is probably the right solution to this problem.
792
00:44:28.800 --> 00:44:31.119
And you know that's what we're in it for, right,
793
00:44:31.159 --> 00:44:33.400
We're in it to solve these problems, right, And so
794
00:44:34.239 --> 00:44:37.440
sometimes it's going to be micro services is you know,
795
00:44:37.800 --> 00:44:40.920
a terrific way to solve the problem. And sometimes it's
796
00:44:40.920 --> 00:44:43.760
going to be, hey, you know, we need to keep
797
00:44:43.800 --> 00:44:45.719
all this stuff together so that it kind of all
798
00:44:45.760 --> 00:44:51.280
moves and works together in this way. And sometimes we're
799
00:44:51.360 --> 00:44:52.800
going to be in a situation where we just have
800
00:44:52.800 --> 00:44:53.639
to make a judgment call.
801
00:44:54.079 --> 00:44:55.039
And so I like that.
802
00:44:55.039 --> 00:44:57.760
That's where this conversation is gone, where it's hey, look,
803
00:44:58.079 --> 00:44:59.760
these are some of the trade offs that come in
804
00:44:59.800 --> 00:45:02.920
this way or that way, and these are some of
805
00:45:02.960 --> 00:45:04.480
the considerations you're going to wind to make in.
806
00:45:04.679 --> 00:45:07.639
Yeah, that's really that's really well said. These are different
807
00:45:07.639 --> 00:45:10.960
tools in the toolbox, and yeah, solve solving problems is
808
00:45:10.960 --> 00:45:13.639
one of the greatest parts about being, you know, an
809
00:45:13.639 --> 00:45:16.880
engineer and doing what we do probably closely followed by
810
00:45:16.880 --> 00:45:20.559
seeing our users and customers actually get to take advantage
811
00:45:20.559 --> 00:45:23.679
of these these creations that we out into the world.
812
00:45:24.039 --> 00:45:27.480
Yep, absolutely, because I mean, let's face it, if you
813
00:45:27.679 --> 00:45:33.320
have a really pro team that follows wonderful practices, they're
814
00:45:33.440 --> 00:45:38.039
very consistent and there's no hidden surprises, and if you
815
00:45:38.719 --> 00:45:43.079
create a monolith, then it's going to be very maintainable,
816
00:45:43.360 --> 00:45:46.320
it's going to be well tested and you're not going
817
00:45:46.400 --> 00:45:49.239
to have any problems. Take that in compared to a
818
00:45:49.360 --> 00:45:53.880
team that is not very well versed. They are not
819
00:45:54.079 --> 00:45:59.039
consistent and they're creating micro services. Now you have an
820
00:45:59.079 --> 00:46:02.639
application which consists of one hundred microsurfaces and each one
821
00:46:02.760 --> 00:46:07.119
is its own nightmare. So and it can go either way.
822
00:46:07.519 --> 00:46:10.360
You have a team that's great with micro services, they're
823
00:46:10.400 --> 00:46:14.119
great with practices, and everything is consistent and isolated in
824
00:46:14.159 --> 00:46:16.679
these micro services, and it's could be a great application.
825
00:46:16.760 --> 00:46:19.039
But then you have a team that's not as well
826
00:46:19.119 --> 00:46:23.559
versed and they are just creating an insane monolith that
827
00:46:23.719 --> 00:46:28.960
is just unmaintainable. So it's a healthy balance of choosing
828
00:46:29.000 --> 00:46:31.320
the right tool for the job and making sure that
829
00:46:31.360 --> 00:46:35.000
you have the team and budget to match, as well
830
00:46:35.039 --> 00:46:39.920
as the infrastructure budget to host, because as we said,
831
00:46:40.000 --> 00:46:45.679
there could be differences in which direction you go. So overall,
832
00:46:46.440 --> 00:46:50.480
I think that because I've worked primarily on Ruby on
833
00:46:50.559 --> 00:46:54.800
Rails applications, micro services doesn't really have a fit in
834
00:46:54.840 --> 00:46:59.360
my world because I think the convention over configuration that
835
00:46:59.480 --> 00:47:03.000
Rails his provided me, plus the practices that I have
836
00:47:03.159 --> 00:47:08.880
developed over the past ten twelve years, has really negated
837
00:47:08.960 --> 00:47:12.360
the need for micro services in my world. But that
838
00:47:12.440 --> 00:47:16.280
could be a different story for someone else where micro
839
00:47:16.360 --> 00:47:18.159
services is the answer for them.
840
00:47:18.480 --> 00:47:22.079
Yeah, I also just want to I should point out
841
00:47:22.360 --> 00:47:25.679
so the app that I work on primarily these days
842
00:47:26.039 --> 00:47:28.480
for my full time job, it was written to replace
843
00:47:28.519 --> 00:47:31.400
another app that was written in another framework, in another language,
844
00:47:31.880 --> 00:47:36.719
and essentially it was written very quickly by some very
845
00:47:36.719 --> 00:47:38.960
talented engineers. But it was written very quickly, and they
846
00:47:38.960 --> 00:47:40.800
threw a lot of best practices out the window just
847
00:47:40.840 --> 00:47:44.400
to get it out the door. And so we're dealing
848
00:47:44.440 --> 00:47:47.559
with those the fallout of that stuff right now. Right
849
00:47:47.840 --> 00:47:50.039
because we're now in the second year, we're coming back
850
00:47:50.079 --> 00:47:53.800
around to, you know, essentially another iteration of what this
851
00:47:53.840 --> 00:47:58.440
thing does, and you know, and so we're coming into Okay,
852
00:47:58.639 --> 00:47:59.880
we've got to deal with this, and we've got to
853
00:47:59.920 --> 00:48:01.519
do with this, we've got to deal with that, we've
854
00:48:01.519 --> 00:48:04.000
got to deal with you know, these other things. And
855
00:48:04.239 --> 00:48:07.639
it's you know, it's yeah, you know what Dave's saying.
856
00:48:07.679 --> 00:48:11.239
It's just not pretty. And it really does, in a
857
00:48:11.280 --> 00:48:14.400
lot of cases, come down to your discipline and your
858
00:48:14.440 --> 00:48:18.039
willingness to look at these problems and identify where these
859
00:48:18.039 --> 00:48:21.119
things are going to come up right, and so you know,
860
00:48:21.239 --> 00:48:24.760
whether or not you use one architecture or the other,
861
00:48:24.800 --> 00:48:26.920
whether or not you make these decisions one way or
862
00:48:26.960 --> 00:48:29.239
the other, what it really comes down to is your
863
00:48:29.280 --> 00:48:32.519
discipline in implementing them and approaching these problems in a
864
00:48:32.519 --> 00:48:36.559
way that is going to solve the problem in the
865
00:48:36.599 --> 00:48:40.360
long term. And RAILS does a lot of things that
866
00:48:40.440 --> 00:48:44.199
makes it really easy for you to approach this. From
867
00:48:44.239 --> 00:48:47.000
the majestic monolith, I kept saying beautiful monolith at the
868
00:48:47.039 --> 00:48:49.760
beginning because I couldn't remember the word that dhhused in
869
00:48:49.880 --> 00:48:52.480
his blog article. And I have the article up now
870
00:48:52.519 --> 00:48:55.679
in front of me, so I'll put on link in
871
00:48:55.719 --> 00:48:58.440
the show notes. But you know, and that's his approach
872
00:48:58.480 --> 00:49:01.039
and so that's the approach to the from rails. But
873
00:49:01.239 --> 00:49:03.679
as Darren pointed out, you know, there are a lot
874
00:49:03.679 --> 00:49:06.159
of things in there because it's built on rack that
875
00:49:06.320 --> 00:49:09.320
it does exceptionally well. That allows you to break it
876
00:49:09.360 --> 00:49:13.239
out into services if you need to. And so because
877
00:49:13.280 --> 00:49:17.079
of that, it makes it, you know, really versatile in
878
00:49:17.119 --> 00:49:20.559
your approach, and so you know, find the approach that
879
00:49:20.599 --> 00:49:23.760
works for you and then just be disciplined in the
880
00:49:23.760 --> 00:49:26.119
way that you approach it so that it does the
881
00:49:26.119 --> 00:49:27.760
work that you need it to do, solve the problem
882
00:49:27.800 --> 00:49:30.280
that you need to solve. And that's the that like,
883
00:49:30.280 --> 00:49:32.360
like Darren said, this is the really great part is
884
00:49:32.400 --> 00:49:34.239
that we get to go in and we get to
885
00:49:34.280 --> 00:49:36.719
figure out the pieces to the puzzle. It's like playing
886
00:49:36.719 --> 00:49:38.880
a video game, except at the end of the day
887
00:49:39.400 --> 00:49:42.960
it's not the prescribed path through the level. It's the Hey,
888
00:49:43.000 --> 00:49:44.519
at the end of the day, we got the problem
889
00:49:44.639 --> 00:49:46.639
solved and we get to do some really cool stuff
890
00:49:46.679 --> 00:49:47.920
along the way to figure it out.
891
00:49:49.079 --> 00:49:51.280
Yeah, those two points, those two points were spot on.
892
00:49:51.400 --> 00:49:53.199
Right at the end of the day, there's no there's
893
00:49:53.239 --> 00:49:57.719
no until AI advances to another level, maybe there's no
894
00:49:58.280 --> 00:50:01.480
replacement for the design and the discipline, Right, So you
895
00:50:01.519 --> 00:50:03.679
do that design upfront and it's like what's best for
896
00:50:03.760 --> 00:50:07.480
my situation, and then the discipline. I think that you know,
897
00:50:07.599 --> 00:50:10.480
even after you've agreed on the design, I think there's
898
00:50:10.519 --> 00:50:14.639
no substitute for those code reviews, right, Like, that's that's
899
00:50:14.679 --> 00:50:17.559
where you're really like, Okay, are we are we really
900
00:50:17.719 --> 00:50:19.559
doing what we said we were going to do? We
901
00:50:19.679 --> 00:50:22.480
are we following our guidelines? You know. That's how you
902
00:50:22.519 --> 00:50:24.400
make sure that you accomplish that goal and you don't
903
00:50:24.480 --> 00:50:26.519
end up kind of in a situation like you describe,
904
00:50:26.519 --> 00:50:28.320
where a lot of people find themselves with a code
905
00:50:28.360 --> 00:50:31.679
base that has a life of its own, its own personality,
906
00:50:32.039 --> 00:50:35.239
for whatever reason that it ended up being created that way. Right,
907
00:50:35.280 --> 00:50:38.199
there's always reasons that at the time that get applied,
908
00:50:38.239 --> 00:50:41.920
but there's just no substitute for those things. Yeah. I've
909
00:50:41.960 --> 00:50:45.239
worked previously. I worked in environments where we did not
910
00:50:45.360 --> 00:50:48.679
review every line of code, and then more recently I did,
911
00:50:48.719 --> 00:50:51.679
And it's hard to imagine not having code reviews for
912
00:50:51.719 --> 00:50:52.679
everything anymore.
913
00:50:52.920 --> 00:50:55.039
Yeah, So real quick, I'm going to throw out a
914
00:50:55.039 --> 00:50:57.719
couple of resources and then we'll get to picks. One
915
00:50:57.800 --> 00:50:59.880
is you mentioned machine learning and AI and I have
916
00:51:00.079 --> 00:51:02.840
to say, we have a machine learning podcast. You can
917
00:51:02.880 --> 00:51:05.119
go check it out at Adventures machine Learning. Just go
918
00:51:05.159 --> 00:51:07.719
to devchat dot tv click podcasts up at the top
919
00:51:07.840 --> 00:51:10.519
and it's right there Adventures and machine Learning. Or you
920
00:51:10.559 --> 00:51:13.239
can find it in your favorite podcast app. Just do
921
00:51:13.320 --> 00:51:14.840
it search Adventures in Machine Learning.
922
00:51:14.880 --> 00:51:15.519
You'll find it.
923
00:51:15.519 --> 00:51:18.559
It's got kind of a face and some artwork. Anyway,
924
00:51:18.800 --> 00:51:21.000
it looks really cool and I'm very proud of it.
925
00:51:21.239 --> 00:51:23.960
And yeah, one of the hosts, he's a really good
926
00:51:24.000 --> 00:51:29.360
looking guy. And yeah, Migael's pretty cool too. The other
927
00:51:29.519 --> 00:51:31.159
one that I'm going to throw out there, and you know,
928
00:51:31.159 --> 00:51:34.199
because we're talking about discipline and practices and things like that.
929
00:51:34.400 --> 00:51:37.480
I had a really terrific conversation with Bob Martin about
930
00:51:37.559 --> 00:51:42.400
clean craftsmanship and he talked about practices. Oh man, I'm
931
00:51:42.400 --> 00:51:47.079
gonna blow this so hard. Practices. There were three levels
932
00:51:47.119 --> 00:51:51.000
to it. The third one was ethics practicals. I think
933
00:51:51.000 --> 00:51:55.599
it was disciplines. Principles was the principles anyway, go listen
934
00:51:55.639 --> 00:51:57.079
to it because he breaks it down. And the first
935
00:51:57.159 --> 00:52:01.079
level was he talks about TDD pairing. You know those
936
00:52:01.159 --> 00:52:03.039
kinds of things where you know, like you're talking about
937
00:52:03.079 --> 00:52:06.119
the code reviews kind of falls underpairing, right, and then
938
00:52:06.320 --> 00:52:10.880
testing of some kind right under TDD, you know, and
939
00:52:10.920 --> 00:52:13.679
some of these other things where you're just doing these
940
00:52:13.800 --> 00:52:15.079
practices that get you to.
941
00:52:15.119 --> 00:52:15.800
Where you need to go.
942
00:52:15.880 --> 00:52:17.800
And then you have standards, right, That's what it was.
943
00:52:17.840 --> 00:52:20.920
It with standards, and so what are your code standards? Right,
944
00:52:21.039 --> 00:52:23.760
that make the code the kind of quality that you
945
00:52:23.800 --> 00:52:26.199
have to do. And then the ethics where you know,
946
00:52:26.280 --> 00:52:28.840
the kinds of things where it's and he has the
947
00:52:28.880 --> 00:52:31.119
programmer's oath is what he calls it, and we kind
948
00:52:31.119 --> 00:52:31.679
of talked through that.
949
00:52:31.719 --> 00:52:32.519
We have another.
950
00:52:32.239 --> 00:52:34.920
Episode where we talked about that on the Clean Coders podcast,
951
00:52:35.199 --> 00:52:37.320
But he talks about you know, hey, you know, am
952
00:52:37.320 --> 00:52:40.159
I making the code based better? Am I delivering for
953
00:52:40.199 --> 00:52:42.679
the company that's paying me for my time? Am I
954
00:52:43.239 --> 00:52:45.960
delivering code that meets the kind of standards? Am I
955
00:52:45.960 --> 00:52:49.519
improving my skills so that I can deliver for my team?
956
00:52:49.679 --> 00:52:52.480
And you know, things like that, and anyway, it was
957
00:52:52.559 --> 00:52:55.320
really really interesting conversation and that's the kind of thing
958
00:52:55.320 --> 00:52:57.880
that we really need to be talking about too, within
959
00:52:58.079 --> 00:53:00.519
our within our teams and with the people that we
960
00:53:00.559 --> 00:53:02.760
work with, because at the end of the day, it's
961
00:53:02.840 --> 00:53:06.400
not just Hey, here's the technology and the technical approach
962
00:53:06.400 --> 00:53:09.360
that we used to solve the problem, but it's yeah,
963
00:53:09.400 --> 00:53:11.039
what are we doing to make sure that it's the
964
00:53:11.119 --> 00:53:13.440
right solution to the right problem. What are we doing
965
00:53:13.440 --> 00:53:15.320
to make sure that the code meets the standards that
966
00:53:15.360 --> 00:53:18.920
we have for the kinds of solutions we deliver, and
967
00:53:18.960 --> 00:53:20.800
what kinds of things are we doing day to day
968
00:53:21.440 --> 00:53:23.559
in order to make sure that we are delivering for
969
00:53:23.679 --> 00:53:26.199
the company that we work for, delivering for the team
970
00:53:26.239 --> 00:53:29.159
we work with, delivering for the world at large, and
971
00:53:29.199 --> 00:53:32.239
things like that. So anyway, terrific conversation. I'll put both
972
00:53:32.280 --> 00:53:34.599
of those links in the show notes, and yeah, let's
973
00:53:34.599 --> 00:53:37.679
go ahead and new picks. I'm going to push it today. First, Dave,
974
00:53:37.679 --> 00:53:38.639
do you have some picks for us?
975
00:53:39.119 --> 00:53:42.719
Yeah? Sure, So my first pick is a pack tool
976
00:53:42.920 --> 00:53:46.360
Gecko Gauge. If you've ever had to work with hardyboard,
977
00:53:46.440 --> 00:53:48.800
which is the cement fiber boards that you put on
978
00:53:48.880 --> 00:53:53.360
the side of houses, then this tool is amazing. It
979
00:53:53.440 --> 00:53:56.760
allows you to just clamp onto the previous fiber board
980
00:53:56.760 --> 00:53:59.840
that you installed and then set the new one just
981
00:54:00.239 --> 00:54:04.039
right on top. It'll be completely leveled to the other one.
982
00:54:04.519 --> 00:54:08.599
It is a life saving tool for working with hardyboard.
983
00:54:09.079 --> 00:54:10.679
And the whole reason why I picked this up is
984
00:54:10.719 --> 00:54:14.400
because I'm building a shed underneath our deck and I'm
985
00:54:14.440 --> 00:54:16.840
now getting around to the part where I'm doing the
986
00:54:16.920 --> 00:54:19.159
sighting to make it look like the rest of the house.
987
00:54:19.920 --> 00:54:21.519
I was not going to be able to do this
988
00:54:21.639 --> 00:54:24.840
job without that tool. So it's amazing. And on the
989
00:54:24.960 --> 00:54:29.559
date of recording this podcast today is April first, i
990
00:54:29.719 --> 00:54:33.400
launched a new tutorial site. So I've been doing drift
991
00:54:33.440 --> 00:54:37.360
and Ruby for many, many years, over two hundred eighty
992
00:54:37.559 --> 00:54:41.480
episodes I've recorded on Ruby and Ruby on rails, and
993
00:54:41.559 --> 00:54:44.960
so today I've launched a new training site and that
994
00:54:45.159 --> 00:54:48.800
is drifting Cobal. So you can go to driftingcobyl dot
995
00:54:48.840 --> 00:54:52.360
com and you'll see that it's a completely satire side
996
00:54:52.400 --> 00:54:58.719
for April first, but hey, if it picks up one subscriber,
997
00:54:58.840 --> 00:55:02.000
that's like ten percent of the entire Cobalt user base,
998
00:55:02.360 --> 00:55:03.360
so I'd say that's when.
999
00:55:03.800 --> 00:55:07.800
Wow, that's amazing. I actually did Cobal when I first
1000
00:55:07.840 --> 00:55:12.039
started programming dating myself again, so this is great to see.
1001
00:55:13.559 --> 00:55:17.400
Nice, very cool. I'm gonna have to is that a
1002
00:55:17.400 --> 00:55:18.000
punch card?
1003
00:55:18.360 --> 00:55:21.960
It is nice, It's not a real punch card. The
1004
00:55:22.000 --> 00:55:25.000
real punch cards were more like the this is.
1005
00:55:25.199 --> 00:55:28.880
This looks like a copy book description almost Yeah, your
1006
00:55:28.960 --> 00:55:30.280
data formats.
1007
00:55:29.800 --> 00:55:31.880
And oh I'm tweeting it right now.
1008
00:55:34.000 --> 00:55:35.719
It is a good It is a good call out
1009
00:55:35.760 --> 00:55:38.639
that we are recording this on April first. When you
1010
00:55:38.679 --> 00:55:40.440
all asked me to be a guest on the podcast,
1011
00:55:40.480 --> 00:55:43.159
I wasn't sure if you were joking or serious.
1012
00:55:45.119 --> 00:55:48.119
Hey, you scheduled it not us fair enough?
1013
00:55:48.159 --> 00:55:48.719
Fair enough?
1014
00:55:48.960 --> 00:55:51.239
Yeah, all right, I've got a couple of picks I'm
1015
00:55:51.239 --> 00:55:53.440
gonna throw out there. The first pick that I have
1016
00:55:54.239 --> 00:55:56.559
is I've been using this tool I'm really liking. It
1017
00:55:56.639 --> 00:56:00.239
is called click up now. If you have used no
1018
00:56:00.239 --> 00:56:02.360
notion dot so I've picked it on the show before.
1019
00:56:02.960 --> 00:56:05.800
Notion is kind of an all in one how do
1020
00:56:05.840 --> 00:56:07.840
I put it? It's supposed to be kind of a
1021
00:56:07.840 --> 00:56:14.880
wiki slash, trellos slash, to do list slash anyway, it
1022
00:56:14.960 --> 00:56:19.000
does not have any kind of automation, and it doesn't
1023
00:56:19.079 --> 00:56:22.760
integrate with Zapier, and so I quit using it eventually
1024
00:56:22.800 --> 00:56:23.679
because I just couldn't.
1025
00:56:23.880 --> 00:56:25.519
I couldn't do with it what I wanted to do.
1026
00:56:25.679 --> 00:56:25.840
Right.
1027
00:56:26.480 --> 00:56:28.360
Well, clickup has all that stuff built in and what
1028
00:56:28.400 --> 00:56:31.119
it doesn't have built in it actually integrates with Zapier.
1029
00:56:31.679 --> 00:56:36.360
So I'm really really loving this tool, and so I'm
1030
00:56:36.400 --> 00:56:38.639
actually moving as many of the workflows for.
1031
00:56:38.599 --> 00:56:40.360
Devchat dot tv over to it as I can.
1032
00:56:40.760 --> 00:56:42.920
A lot of the stuffs still on Trello, and that's
1033
00:56:42.920 --> 00:56:44.880
where I wound up moving a lot of this stuff too,
1034
00:56:45.400 --> 00:56:47.519
so it's going to take some time to move it over.
1035
00:56:47.920 --> 00:56:49.920
But I am really really looking forward to some of
1036
00:56:49.960 --> 00:56:53.360
this stuff. I can actually include some of the other
1037
00:56:53.599 --> 00:56:56.280
folks from dev chat dot tv on it, and so
1038
00:56:56.400 --> 00:57:00.639
I'm looking at instead of for example, we have some
1039
00:57:00.760 --> 00:57:05.360
automation that's built into Zappier that's supposed to like pick
1040
00:57:05.440 --> 00:57:10.920
things up and send out a calendar invite and set
1041
00:57:10.960 --> 00:57:13.960
up a Google doc and do all this stuff. And
1042
00:57:14.000 --> 00:57:15.760
I'm hoping that I can move all of that into
1043
00:57:15.800 --> 00:57:20.079
clickup and then just invite our podcast guests as guests
1044
00:57:20.239 --> 00:57:22.920
on the test. That's the only part of it. I
1045
00:57:22.920 --> 00:57:27.280
can't guarantee what'll work because I haven't double checked on that,
1046
00:57:27.840 --> 00:57:30.559
But for the hosts and everybody else, I can actually
1047
00:57:30.639 --> 00:57:32.559
go in and do that, and I'm hoping to be
1048
00:57:32.559 --> 00:57:35.079
able to automate all of that stuff so that then
1049
00:57:35.119 --> 00:57:38.119
it comes back after the episode and says, because we
1050
00:57:38.280 --> 00:57:40.679
manually have to follow up, Hey, can we get a
1051
00:57:40.719 --> 00:57:43.400
description for the episode and a title for the episode?
1052
00:57:43.440 --> 00:57:45.719
And because I'm not on all the shows, and so
1053
00:57:45.800 --> 00:57:47.519
I'm kind of the backup on the shows that I
1054
00:57:47.559 --> 00:57:51.159
show up for. But if I'm sick or if I'm
1055
00:57:51.199 --> 00:57:53.159
just not on the show like Adventures in dot Net,
1056
00:57:53.719 --> 00:57:56.480
I'm practically useless on that show anyway, Right, I can
1057
00:57:56.519 --> 00:57:58.239
kind of make it up and go look up the terms.
1058
00:57:58.280 --> 00:58:02.360
I don't know, but realist, right, if they're talking about
1059
00:58:02.360 --> 00:58:06.760
like some deep library NC SHARP, it's like, okay, what
1060
00:58:07.000 --> 00:58:07.559
is this thing?
1061
00:58:07.639 --> 00:58:07.840
Right?
1062
00:58:07.880 --> 00:58:09.320
And I have to go do some research.
1063
00:58:09.760 --> 00:58:12.480
So that's what I'm looking at doing, is just automating
1064
00:58:12.480 --> 00:58:15.440
the crap out of that. And so I'm pretty excited
1065
00:58:15.440 --> 00:58:17.639
about that and working through it.
1066
00:58:18.119 --> 00:58:20.599
But if it lets me automate all of that stuff,
1067
00:58:21.280 --> 00:58:22.679
I'm going to be one happy dude.
1068
00:58:23.079 --> 00:58:25.159
And so I'm going to pick that. The other thing
1069
00:58:25.199 --> 00:58:28.320
that I am also going to pick is dev influencers.
1070
00:58:28.719 --> 00:58:32.119
So dev influencers dot com. You've heard me talk about
1071
00:58:32.119 --> 00:58:35.519
dev heroes, that's now dev influencers. So if you're looking
1072
00:58:35.599 --> 00:58:38.920
at kind of that next stage, or if you're in
1073
00:58:38.960 --> 00:58:42.960
a position like Darren, where you're a developer, evangelist, or
1074
00:58:43.000 --> 00:58:46.440
you're trying to you know, gain some kind of audience,
1075
00:58:47.000 --> 00:58:49.800
you know, where you're trying to get noticed. I'm putting
1076
00:58:49.800 --> 00:58:53.960
together basically a coaching program and I currently have five
1077
00:58:54.039 --> 00:58:57.280
people in there where I'm coaching them every week on Okay,
1078
00:58:57.280 --> 00:59:00.000
here's how you build an audience. I'm focused on podcasts,
1079
00:59:00.519 --> 00:59:02.639
So here's how you build an audience. Here's how you
1080
00:59:02.960 --> 00:59:05.480
build your podcast. Here's how you get people to listen
1081
00:59:05.519 --> 00:59:07.639
to it, Here's how you grow it. And then from
1082
00:59:07.719 --> 00:59:10.400
there it's here's how you build it into Some people
1083
00:59:10.400 --> 00:59:13.360
want to do speaking, some people want to teach live training,
1084
00:59:13.440 --> 00:59:14.760
some people want to do courses.
1085
00:59:14.840 --> 00:59:15.719
Some people want to do.
1086
00:59:15.679 --> 00:59:17.920
I mean, you know, there are all these options. Build
1087
00:59:17.920 --> 00:59:20.960
their freelancing practice, get a better job. All of those
1088
00:59:20.960 --> 00:59:24.960
things are things that I have done out of podcasting
1089
00:59:25.119 --> 00:59:27.480
while I'm working on the course. But all the other
1090
00:59:27.480 --> 00:59:28.159
things are things.
1091
00:59:28.000 --> 00:59:28.880
That I've done out of it.
1092
00:59:29.000 --> 00:59:31.239
Right, I have a book that I've written that I've
1093
00:59:31.239 --> 00:59:33.760
sold off to the back of the podcast, and so
1094
00:59:33.960 --> 00:59:35.679
if that's something you're interested and you can go check
1095
00:59:35.719 --> 00:59:38.320
it out. But if you want a podcast about it,
1096
00:59:38.599 --> 00:59:40.400
I'm putting that out too, So go check it out
1097
00:59:40.400 --> 00:59:44.119
dev influencers dot Com slash podcast and you can check
1098
00:59:44.159 --> 00:59:46.800
that out there. You can also go to dev influencers
1099
00:59:46.840 --> 00:59:51.400
dot com slash apply and you'll put your email and
1100
00:59:51.519 --> 00:59:54.280
name in. And that's just so that some people, for
1101
00:59:54.360 --> 00:59:58.440
whatever reason, they hit the thing on their phone, the application,
1102
00:59:58.559 --> 01:00:01.039
and then for whatever reason they don't get the information in.
1103
01:00:01.360 --> 01:00:03.400
That's so that I can just remind them, hey, look, yah,
1104
01:00:03.480 --> 01:00:05.960
filled it out. Can you come back right? And then
1105
01:00:05.960 --> 01:00:08.559
I'm planning on sending some emails out and some other stuff,
1106
01:00:08.559 --> 01:00:12.239
putting some other stuff together there. But yeah, dev influencers
1107
01:00:12.280 --> 01:00:13.960
dot Com that's where all that stuff's going to be
1108
01:00:13.960 --> 01:00:16.119
for the podcast, and I'm going to be talking about
1109
01:00:16.119 --> 01:00:18.360
how to advance your career. A lot of people they
1110
01:00:18.360 --> 01:00:20.239
get stuck at senior developer, that's the other thing, and
1111
01:00:20.239 --> 01:00:22.039
they're like, I don't want to be a manager. I
1112
01:00:22.079 --> 01:00:25.039
don't really want to go architecture or whatever. I want
1113
01:00:25.079 --> 01:00:27.039
to keep writing code and this is a way you
1114
01:00:27.039 --> 01:00:29.960
can do that. So anyway, dev influencers dot Com. That's
1115
01:00:30.000 --> 01:00:33.039
kind of my thing. And that's not an April Fool's joke. Darren,
1116
01:00:33.400 --> 01:00:34.400
Do you have some picks for us.
1117
01:00:34.559 --> 01:00:36.519
Yeah, well, I'm going to go ahead and mention if
1118
01:00:36.559 --> 01:00:39.960
you like Ruby and rails and you like the getting
1119
01:00:40.000 --> 01:00:42.760
those benefits of containers that I talked about, definitely check
1120
01:00:42.760 --> 01:00:46.599
out engine yard containers. That's our the next generation platform.
1121
01:00:46.639 --> 01:00:49.360
You can go to engine yard dot com. You can
1122
01:00:49.400 --> 01:00:52.159
also on that site go under resources on the blog.
1123
01:00:52.199 --> 01:00:55.360
You can check out my Ruby Unbundled blog where we
1124
01:00:55.400 --> 01:00:58.320
talk about the different architecture concepts and and other cool
1125
01:00:58.880 --> 01:01:01.800
things that I find fascinating about Ruby. But yeah, so
1126
01:01:02.000 --> 01:01:04.639
engine Yard containers is a great way to quickly deploy
1127
01:01:04.679 --> 01:01:08.000
those Ruby apps, scale them up, and get some of
1128
01:01:08.000 --> 01:01:11.079
those observability and other benefits we talked about. Am I
1129
01:01:11.119 --> 01:01:12.679
allowed to do that for a pick? Is that okay?
1130
01:01:12.840 --> 01:01:13.360
Absolutely?
1131
01:01:14.920 --> 01:01:16.960
We usually ask you to at the end where people
1132
01:01:16.960 --> 01:01:18.880
can find you, So that's that does help.
1133
01:01:19.119 --> 01:01:22.599
I'm ahead of the game, yep, I would. I would
1134
01:01:22.599 --> 01:01:25.079
throw in mentioned the other app Land is a really
1135
01:01:25.159 --> 01:01:27.599
nice way to figure out what's going on with your
1136
01:01:27.599 --> 01:01:30.159
codebase as well. I would throw that out there as
1137
01:01:30.199 --> 01:01:32.559
my other pick they have. I think app map is
1138
01:01:32.599 --> 01:01:35.559
actually the gem. App Land is a site if you
1139
01:01:35.559 --> 01:01:38.519
want to share those across different users on your project.
1140
01:01:38.840 --> 01:01:40.000
Awesome. All right.
1141
01:01:40.320 --> 01:01:44.400
Well, and then I'm assuming you're also on Twitter and facebo, Facebook, Twitter,
1142
01:01:44.440 --> 01:01:44.960
and GitHub.
1143
01:01:45.320 --> 01:01:49.440
I am at Darren Bramer d A R R E
1144
01:01:49.559 --> 01:01:51.800
N b r O E M M E R. I
1145
01:01:51.840 --> 01:01:53.679
probably need to get a better Twitter handle, don't I
1146
01:01:54.159 --> 01:01:58.000
that's too complicated, but it is my name, so you can.
1147
01:01:58.079 --> 01:02:00.960
You can find me there. And on GitHub, I have
1148
01:02:01.079 --> 01:02:04.000
my old user ID, just letter D and then the
1149
01:02:04.039 --> 01:02:06.360
first seven letters of my last name, D Bromine, so
1150
01:02:06.599 --> 01:02:07.559
that's me on GitHub.
1151
01:02:07.639 --> 01:02:09.639
All right, cool, all right, well, thank you for coming.
1152
01:02:09.679 --> 01:02:12.039
This was really really fun. Yeah, thanks you so much
1153
01:02:12.039 --> 01:02:13.159
for having me. This was great.
1154
01:02:13.480 --> 01:02:15.800
Yeah, it's fun to argue about architecture, right.
1155
01:02:16.400 --> 01:02:17.440
I love it. I love it.
1156
01:02:18.800 --> 01:02:21.000
This is what it's all about, all right, folks. Well
1157
01:02:21.079 --> 01:02:22.280
until next week, Max out