Speaker 1: Hey everybody, and welcome to another episode of the Ruby
Speaker 1: Rogues podcast. This week, on our panel we have Dave Kamia.
Speaker 1: Hey everyone, I'm Charles max Food from duv chat dot tv. Dave,
Speaker 1: It's nice to do a podcast with you again.
Speaker 2: It's been a while, hasn't it.
Speaker 1: I know, I keep winding up showing up when you
Speaker 1: can't make it, and then you show up when I
Speaker 1: can't make it. Yeah, of course now we both show
Speaker 1: up and Luke and John can't make it. So one
Speaker 1: of these days we also have a special guest, and
Speaker 1: that's Darren Bromer.
Speaker 3: Did I say that right, Darren?
Speaker 4: Yeah, Darren Bramer, Yeah, Bramer. Ah, I had a oe,
Speaker 4: said German. German a sound.
Speaker 3: Ah nice, sou.
Speaker 1: Do you want to introduce yourself, let people know who
Speaker 1: you are while you're important and famous and all that
Speaker 1: cool stuff.
Speaker 4: Absolutely? Yeah. Well, first of all, thanks a lot for
Speaker 4: having me on here. It's great to talk with you guys.
Speaker 4: So I've been engineer engineering my whole life. I will
Speaker 4: admit that I discovered Ruby a little bit later in
Speaker 4: my career. I was the Java guy for quite a
Speaker 4: while and going all the way back to two thousand
Speaker 4: and two, I'm going to date myself here. I wrote
Speaker 4: a book on Java J twoee. Actually, so there you go.
Speaker 4: There's a data bit of technology a little bit, and
Speaker 4: so I've done all types of engineering managed teams. I
Speaker 4: decided I wanted to go back get hands on keyboard.
Speaker 4: After doing that, went to Amazon Web Services, had a
Speaker 4: great time working there, learned a whole lot, had a
Speaker 4: lot of fun, met a lot of great people, and
Speaker 4: then wanted to get more into kind of combined the
Speaker 4: two things I really really enjoy, so the technology obviously,
Speaker 4: but also communications. And so now I kind of kind
Speaker 4: of went and switched gears of now the developer evangelist
Speaker 4: for engine Yard, and we have platforms of service tools.
Speaker 4: But I get to do my two favorite things, which
Speaker 4: are play with technology and share that with people, write
Speaker 4: about it and talk about it.
Speaker 3: Awesome.
Speaker 1: And yeah, we ran across this article from you talking
Speaker 1: about architecture and micro services and stuff, which is funny
Speaker 1: because I think on JavaScript jabber. We did an episode
Speaker 1: on micro front ends about three weeks ago. We recorded it. Anyway,
Speaker 1: we're a little more ahead on that, so it's probably
Speaker 1: going to come out in a few weeks. But it's
Speaker 1: just interesting because people are talking about this and how
Speaker 1: to break up application logic and stuff like that, and
Speaker 1: of course in RAILS we all talked about the beautiful
Speaker 1: monolith and you know how that all kind of comes
Speaker 1: together to put it all in one app. And so, yeah,
Speaker 1: I'm kind of interested because I don't know that I
Speaker 1: necessarily got the breakdown on where you come down on this.
Speaker 1: And I remember early in my career, like soa service
Speaker 1: oriented architecture was a big thing, and I think I
Speaker 1: gave a whole bunch of talks and gave a whole
Speaker 1: bunch of bad advice because it was the cool thing
Speaker 1: to do, and I was really in love with the idea.
Speaker 1: But you know, been built a few apps and took
Speaker 1: it way too far and it was like, you know
Speaker 1: a lot of this stuff really does belong in its
Speaker 1: own app, and then some of this stuff it started okay,
Speaker 1: some of this stuff belongs in workers and some of
Speaker 1: this stuff actually, you know, may belong in its own service,
Speaker 1: you know, micro service. And so you know, I kind
Speaker 1: of have gone back and forth as to how much
Speaker 1: you want to peel off into different parts, and so
Speaker 1: I'm kind of curious where you come down as far
Speaker 1: as Okay, what do I break off into micro services?
Speaker 1: What part do I keep in the monolith? What part
Speaker 1: do I you know, and how do I break that up?
Speaker 1: And then I also saw some stuff about containerization, so
Speaker 1: we can I guess dive into that next. But yeah,
Speaker 1: how do how do microft services kind of fit into
Speaker 1: Ruby these days?
Speaker 4: Yeah? So I think when you're looking at decomposing your
Speaker 4: application and doing design, you know, and and and really
Speaker 4: there's only one reason that we really do software design, right.
Speaker 4: We do it because we're probably going to need to
Speaker 4: change our application tomorrow, whether that be to fix some
Speaker 4: bugs or to add some new features that people want.
Speaker 4: We can't we can't, you know, add patterns and layers
Speaker 4: of indirection everywhere. So we need to make choices. I
Speaker 4: say that because every time you add a layer of indirection,
Speaker 4: there's it's not free. There there's a there's a cost
Speaker 4: to it. Right. We can't optimize to be able to
Speaker 4: change every aspect of the application. You know. For example,
Speaker 4: I've been on a number of projects over my career.
Speaker 4: You know, the team would be, well, we need to
Speaker 4: abstract this and that so that if we want to
Speaker 4: swap out the database later on, we can This is
Speaker 4: maybe a little less relevant now, but I think the
Speaker 4: example still holds, and so there was effort spin into that. Now,
Speaker 4: how many of those projects ever actually swapped out databases?
Speaker 4: You know, I can think of maybe one that went
Speaker 4: from a relational database to a no sequel, and they
Speaker 4: would if they had to make broader changes anyway, So
Speaker 4: you need to you need to think about where can
Speaker 4: I decompose my logic into reusable bits. And when you
Speaker 4: think about the basic rails architecture model view controller, generally speaking,
Speaker 4: you try to push that logic down in that if
Speaker 4: you think about it as a layer down as far
Speaker 4: as you can. You know, validations you'll always need to
Speaker 4: do before you persist to the database. Yeah, put it
Speaker 4: in the in the model class. But it becomes very
Speaker 4: tough when you think about this. You know, there's lots
Speaker 4: of best practice and things about where to put quote
Speaker 4: unquote business logic, and in my experience that often ends
Speaker 4: up coming back to the service level or in rails,
Speaker 4: you know the equivalent of a rail's action a controller method.
Speaker 4: So if I'm a you want your code to mirror
Speaker 4: the real world as closely as possible, and I was
Speaker 4: you know, you mentioned earlier. I've probably given bad advice
Speaker 4: in my career in the past too. I used to
Speaker 4: be huge enthusiast of object oriented and while I think
Speaker 4: it's still valuable and has its place, I think in
Speaker 4: terms of decomposition, if you want to mirror the real world.
Speaker 4: If I'm a customer, I don't think of objects and entities.
Speaker 4: So let's say I'm going to go online to pay
Speaker 4: my credit card bill. I don't think about that in
Speaker 4: terms of, well, there's an account object and a vendor
Speaker 4: and a payment behavior. I think about that of I'm
Speaker 4: going to go pay my bill. You know, it's it's
Speaker 4: an action I take, something I do. And so you
Speaker 4: can try to push logic further down this stack, but
Speaker 4: usually it ends up kind of bubbling back up to
Speaker 4: this service layer because those are encapsulated units of work.
Speaker 4: Now paying your paying your bill that now I personally
Speaker 4: wouldn't do this, But let's say let's say I was
Speaker 4: late on paying my bill, so I'm going to incur
Speaker 4: a fee. So that's probably another service to calculate what
Speaker 4: the late fee is based on when I submit it.
Speaker 4: All of that so you can see you can see
Speaker 4: that kind of breakdown, and so reusing those services. And actually,
Speaker 4: you know, this almost gets back to like functional programming.
Speaker 4: It's funny how things kind of come full circle every
Speaker 4: every so often. But to me, the service level is
Speaker 4: the easiest way to decompose and be close to how
Speaker 4: you mirror the real world. And if you can do that,
Speaker 4: if you can model it closer, you're going to be
Speaker 4: you're going to be better off in the long run
Speaker 4: when you need to make make changes. So now segue
Speaker 4: that into micro service because microservice often has the connotation
Speaker 4: of being a separate physical deployment. So there's different steps
Speaker 4: you can take to migrate this. Right, So you mentioned
Speaker 4: the beautiful monolith. I might have tons of code all
Speaker 4: sitting there. It's in one deployable one deployable unit. You know,
Speaker 4: Rome's not built in a day. I can't do all
Speaker 4: of this at once. So you know, one of the
Speaker 4: articles I wrote that you reference was really just well,
Speaker 4: how do I take that first step? How do I
Speaker 4: go from the beautiful modelith to whatever my target architecture is,
Speaker 4: whatever your favored decomposition model is. So the beautiful thing.
Speaker 4: One really nice thing about rails is I think it
Speaker 4: helps you out here. So even in my existing code
Speaker 4: base a controller action. Let's say you're using rack as
Speaker 4: you're middleware. That controller action is actually a wreck its
Speaker 4: own RACK application. So in the rack up file, rather
Speaker 4: than just doing rails application new, you can actually just
Speaker 4: point it directly to that controller action. So now you
Speaker 4: can deploy that as a deployable unit. It's going to
Speaker 4: use the same code base, but from a logical standpoint,
Speaker 4: I've separated that out from the rest of the system.
Speaker 4: I can begin to reason about it more, think about
Speaker 4: what changes when, how do I reuse things? And then
Speaker 4: just to tease the topic a little bit, just to
Speaker 4: throw the container bit out there so it's an easier
Speaker 4: migration then to make it a separate deployable unit because
Speaker 4: that same image, that same codebase, I'm just going to
Speaker 4: have a different rackup file that I use for each
Speaker 4: of those. I can deploy those separately, I can scale
Speaker 4: them independently, I can observe them. See you know how
Speaker 4: they behave If one if the CPU goes off, the
Speaker 4: rails on one of them is going to be easier
Speaker 4: to identify where the problem was. So you don't get
Speaker 4: those kind of advantages until you actually make them true
Speaker 4: micro services and you get that observability, but there's a
Speaker 4: lot of benefits when you start to go down that road,
Speaker 4: and rails I think helps. Rails gives you tools to
Speaker 4: help do that incrementally. So that's kind of an overview
Speaker 4: of where I'm at. I don't I don't think there's one.
Speaker 4: There's certainly not a one size fits all, but to
Speaker 4: the extent that you can go with micro services to
Speaker 4: break that out from a logical design perspective, and then
Speaker 4: the actual deployment get the observability, scalability independence. I think
Speaker 4: there's a lot of benefit there.
Speaker 2: And so just because I can, I want to push
Speaker 2: back just a little bit and just to get some
Speaker 2: more clarifications. So when we deploy a now isolated bit
Speaker 2: of code as a microservice infrastructure speaking, what is going
Speaker 2: to look like as far as the database level is concerned.
Speaker 2: Are we going to spin up an additional database so
Speaker 2: now we have a whole new database server with a
Speaker 2: new database on there, or would we just create a
Speaker 2: new database within a server. So if we're running postgrads,
Speaker 2: we have one instance of postgrads or a cluster, and
Speaker 2: then we have a new database for this micro service
Speaker 2: and that microservice only communicates to the one database or
Speaker 2: do they all share the same global database.
Speaker 4: Yeah, that's a great question, and you're poking at you
Speaker 4: know why. You want to obviously think through these things carefully,
Speaker 4: but yeah, no, it's a great question. So your your data,
Speaker 4: what does your data architecture look like? If you're starting
Speaker 4: out with the beautiful monolith, you do likely have that
Speaker 4: single transactional database. So to the extent that you can
Speaker 4: segregate out by you know which objects, which models or
Speaker 4: tables are used by sets of services, You're better off
Speaker 4: segregating those and making those their own deployable units. You know,
Speaker 4: you're still going to have some potential level of contention
Speaker 4: because you've got different apps talking to the same database,
Speaker 4: and so you know one could have one could certainly
Speaker 4: impact the other. You can still have a noisy neighbor
Speaker 4: situation there. But as you migrate over time, if you
Speaker 4: can decompose your larger architecture into those discrete topic areas
Speaker 4: where you can have different databases, then you get a
Speaker 4: cleaner isolation, and that typically takes folks a lot longer
Speaker 4: to do. And you can also end up in the
Speaker 4: spot well where I need I need data from from
Speaker 4: both places, and you can end up getting into performance
Speaker 4: issues because you get you know, pretty chatty between these services.
Speaker 4: So so it's not it's not with it's not a
Speaker 4: panacea for sure, but I think to the extent that
Speaker 4: teams can start thinking in that direction and trying to
Speaker 4: find those what are the what are the good isolation
Speaker 4: boundaries to use? And again there is it's not a
Speaker 4: black and white topic, but there's no crystal clear answer,
Speaker 4: but I think there's over overall if you look at
Speaker 4: how do I make changes right? Because in today's economy,
Speaker 4: you know, with the pandemic and people being at home,
Speaker 4: like we were already essentially a digital economy, it's almost
Speaker 4: entirely that way now. So you know, we're all forced
Speaker 4: to innovate so much faster, you know, deploy We were
Speaker 4: already deploying continuously, and now we want to do it
Speaker 4: even more. So if we don't do it fast enough,
Speaker 4: someone else is going to copy our business model, We're
Speaker 4: going to we're going to lose lose customers we could have.
Speaker 4: So there's so much pressure to get features out there faster,
Speaker 4: and so again it's you know, you can't optimize for everything,
Speaker 4: but it's thinking about well, what is going to benefit
Speaker 4: me to isolate where I may want to be able
Speaker 4: to innovate faster move separate from the other aspects of
Speaker 4: the code. One problem that and even at Amazon our
Speaker 4: teams ran into this, especially some of the bigger services,
Speaker 4: where you really want to get a bug fix out
Speaker 4: or some feature out. But if you're all in the
Speaker 4: same if it's all in the same kitten kaboodle, and
Speaker 4: you've got an issue that pops up with one of
Speaker 4: the other changes, you got to roll that whole thing
Speaker 4: back because at the end of the day, you can't
Speaker 4: have impact ongoing impact to your customers. And so that
Speaker 4: is something that I think really hurts teams their velocity
Speaker 4: when you've got to make sure that these twelve or
Speaker 4: twenty or however many features are all working perfectly in
Speaker 4: order to get all of them out the door. So
Speaker 4: rather than an all or nothing, micro services really help
Speaker 4: you there. So you wouldn't isolate everything, but the areas
Speaker 4: where you know you're going to have a focus on,
Speaker 4: or you can predict, or you already know that are
Speaker 4: important to your customers, that's where you may want to
Speaker 4: think about it.
Speaker 1: So one other thing that I'm wondering about because Dave
Speaker 1: was like, well, how do you how do you deal
Speaker 1: with you know, the database level. I'm thinking, how do
Speaker 1: you figure out like traffic coming in right? I mean,
Speaker 1: do you have subdomains, do you have like Varnish or
Speaker 1: something on the front that you know figures out this
Speaker 1: path means this micro service or do you have them
Speaker 1: talk to each other through I've seen like rabbit MQ,
Speaker 1: which I've also seen be a headache. I mean, how
Speaker 1: do you work all that out?
Speaker 4: Yeah, So there's a number of solutions here. I think
Speaker 4: one nice way to start is just too And here's
Speaker 4: where an abstraction does actually benefit you, because you can
Speaker 4: put a facade in front of your service. And so
Speaker 4: maybe you start out with just actually just calling inline.
Speaker 4: You're just calling the class directly in your same Ruby process.
Speaker 4: But that then that positions you so that when you
Speaker 4: do move it out to a service, you can swap
Speaker 4: that out and it's and it's less of a problem
Speaker 4: in terms of the domains I like, I personally like
Speaker 4: having the different subdomains part of that. I guess the
Speaker 4: product that I work with, Engineer facilitates this pretty nicely,
Speaker 4: where each of your apps within the same application just
Speaker 4: get different subdomains. But there's obviously different ways that you
Speaker 4: can do it, and you don't actually you know, of
Speaker 4: course you don't need to split that out because you
Speaker 4: could just use different URL paths to accomplish a similar goal.
Speaker 4: But having the if you get it into containers and
Speaker 4: you can segregate, then you get those benefits of the
Speaker 4: physical deployment also. So to me, I would keep I
Speaker 4: prefer to try to keep it simple. You you know,
Speaker 4: certainly there there's a couple different choices there. I mean
Speaker 4: I would probably if you can't avoid putting messaging layers
Speaker 4: in between, you know that if you can keep it simple,
Speaker 4: rest calls, you're you know, unless you need to do
Speaker 4: something different, I'd probably would advocate for that. You know,
Speaker 4: keep it as simple as possible, but no simpler. But
Speaker 4: there's also other tools and frameworks that help you do that.
Speaker 4: I haven't worked with it in detail, AWSS Service Mesh,
Speaker 4: which helps you orchestrate all of these micro services. So
Speaker 4: there are there are things out there that will that
Speaker 4: will help you manage all of this, and probably those
Speaker 4: are worth it if you really get into large numbers,
Speaker 4: if you really your if your enterprise is you know,
Speaker 4: truly bought in and you're and you're going across many
Speaker 4: different departments in many different organizations. That's probably when you
Speaker 4: when you look at something like that.
Speaker 2: But yeah, so kind of where I'm going with the
Speaker 2: whole database side of things, because I agree, if you
Speaker 2: do have a micro services environment, then you should have
Speaker 2: a separate database for each micro service. But the issue
Speaker 2: kind of comes into play is when you sort off
Speaker 2: with just a few micro services, it's fine, it's easy
Speaker 2: to manage, but then when you scale up to one
Speaker 2: hundred to one thousand to ten thousand, it becomes less manageable,
Speaker 2: and your infrastructure cost also is scaling up fairly.
Speaker 1: Past five and I'm getting a headache.
Speaker 2: So the issue with that scene is when a micro
Speaker 2: service stops becoming a micro service and it becomes a
Speaker 2: monolith service to where you have now these twenty different
Speaker 2: or forty different micro services that just have grown and
Speaker 2: grown and grown, and now you have forty separate, full
Speaker 2: fledged Ruby on Rails applications that are so highly coupled
Speaker 2: and dependent on each other, that would it had been
Speaker 2: better to just have built it into one beautiful, majestic monolith.
Speaker 4: Yeah, I'm I think I had a similar reaction that
Speaker 4: Chuck had. If we get into the thousands, I'm completely
Speaker 4: with you, we've probably gone We've gone off the rails
Speaker 4: at that point.
Speaker 2: I think that's where Netflix is at. I don't know
Speaker 2: how many they have, but I've seen their data map
Speaker 2: of their micro services and communications. It looks like a
Speaker 2: whole globe of just jumbled spaghetti mess.
Speaker 4: I believe that's probably correct. I actually got to work
Speaker 4: with them a little bit when I was at AWS.
Speaker 4: They also are a bit of a snowflake because no,
Speaker 4: I mean, there are very few companies or organizations that
Speaker 4: have the amount of resources that they have. Companies like Netflix,
Speaker 4: like Amazon, you know, there aren't very many folks that
Speaker 4: can put that many resources on it. And they have
Speaker 4: a vast amount of capability as well. I think for
Speaker 4: small and medium sized business, you're looking at a different
Speaker 4: category and a different type of architecture, and it would
Speaker 4: probably not be good if you got into those numbers.
Speaker 4: I will say, on the infrastructure cost point that you
Speaker 4: brought up, I think that would be true on if
Speaker 4: you're on instances or virtual machines. However, containers are very
Speaker 4: efficient at this You can put a lot more container
Speaker 4: processes on the underlying hardware, and you can you also
Speaker 4: get a lot of those other benefits that I that
Speaker 4: I mentioned. So I don't know that the infrastructure cost
Speaker 4: would be quite as bad as you as you think
Speaker 4: it is, because the container processes are pretty lightweight. They
Speaker 4: can start up in milliseconds as opposed to you know,
Speaker 4: like an EC two instance probably takes like between thirty
Speaker 4: and sixty seconds to start up, whereas a container, let's
Speaker 4: say it, let's round it off to a second. So
Speaker 4: you can scale those up and down really really quickly,
Speaker 4: and you can pack a lot more onto a physical
Speaker 4: cluster as well. So I don't know if that would
Speaker 4: be as much of an issue. But on the on
Speaker 4: the complexity front, Tim, I agree, there's some point where
Speaker 4: it becomes unmanageable. Yeah.
Speaker 2: The infrastructure scaling pricing that I was referring to is
Speaker 2: more on the database side, because on a small tier
Speaker 2: database that's really all the application needs. But because you
Speaker 2: have scaled it up to fifty or one hundred micro services,
Speaker 2: you're not going to be able to connect to that
Speaker 2: same database instance with the lower tier plan because the
Speaker 2: number of max connections that's available on those various plans,
Speaker 2: you would have to either spin up multiple database servers,
Speaker 2: in which case you incur scaling costs there, or have
Speaker 2: one really large database server where you have multiple databases
Speaker 2: within there, and then you still incur a higher cost
Speaker 2: just for that max number of connections. Now, AWS may
Speaker 2: have something different now where you can allow more connections,
Speaker 2: but each micro service would need at least its one
Speaker 2: own dedicated connection to the database instance.
Speaker 4: Yeah, unless your databases are of pretty decent size, I
Speaker 4: would probably go the route you mentioned where if you're
Speaker 4: talking AWS, you have an RDS database and you can
Speaker 4: put multiple not instances, multiple schemas on there, right, so
Speaker 4: at least you can segregate it that way. You know,
Speaker 4: if many many of these micro services, if they have
Speaker 4: a smaller footprint, there's not no real reason to have
Speaker 4: a different physical instance, you know, you don't need to
Speaker 4: take that separation to the n degree. Not to be
Speaker 4: too salesy, but we do. The company EngineYard also has
Speaker 4: a scale arc product which is a database proxy, which
Speaker 4: is also a nice way to actually get the three
Speaker 4: tier architecture independence actually separate out your application tier from
Speaker 4: your database by connecting to the proxy and then it
Speaker 4: can talk to all of these other databases make them
Speaker 4: look like different connections, do caching, intelligent caching, and security
Speaker 4: controls for you. Again, if you get into larger number
Speaker 4: of databases, that might be something that's that's helpful. But yeah,
Speaker 4: packing multiple database schemas on the same you know, RDS
Speaker 4: cluster is actually pretty pretty good strategy in a lot
Speaker 4: of cases unless you have a really high volume er,
Speaker 4: a really large sized database.
Speaker 2: Whole container idea instead of the virtual machines I really
Speaker 2: do like and I think that especially even if you
Speaker 2: stick with a monolith version of your application to do
Speaker 2: auto scaling, you can more instantaneously respond to the demand
Speaker 2: coming in opposed to provisioning a whole new virtual machine.
Speaker 2: So I'm really with you on there with using doctor
Speaker 2: containers and stuff like that, because I think that's the
Speaker 2: proper way to do auto scaling because you get instant
Speaker 2: reaction to your users instead of having to wait, Okay,
Speaker 2: we're at a fifty percent usage load across all our vms.
Speaker 2: We need to hurry up and add more servers, all automatically,
Speaker 2: of course, But then fifteen minutes later the server's provision
Speaker 2: and now it's ready. Well, that traffic's all said and done.
Speaker 4: Now absolutely, so yeah, these those two things that we've
Speaker 4: been talking about, the micro services and the containers are
Speaker 4: most certainly independent. So like you were just saying, even
Speaker 4: with beautiful monolith, containers give you a lot of benefit.
Speaker 4: They give you this scale, really fast scalability that you
Speaker 4: just talked about, and something we haven't even mentioned yet,
Speaker 4: it's actually pretty nice for development as well. So developing
Speaker 4: with containers really helps cut down on how many times,
Speaker 4: how much time in my career have I spent getting
Speaker 4: my workstation, my development environment set up the way that
Speaker 4: I want it, and you know, managing those things. So
Speaker 4: using containers for development is really nice for that. There's
Speaker 4: also some really nice tooling to help out there as well,
Speaker 4: so we offer dev spaces. There's also an open source
Speaker 4: gipod where you can with a single click bring up
Speaker 4: the online ide. It's running based on the container that
Speaker 4: you define, and you can also do some simple automation,
Speaker 4: so for example, you can have it on startup, do
Speaker 4: your bundle, install, start your rail server. It opens up
Speaker 4: a preview window inside of your online ide, which is
Speaker 4: based roughly it's based roughly on vs code, so you
Speaker 4: can use those extensions as well, so, yeah, so you
Speaker 4: get benefits from containers, not just in the deployment, but
Speaker 4: I think in the development as well, and you know,
Speaker 4: hopefully never have to hear the phrase works on my machine. Again.
Speaker 4: That helps to alleviate some of those issues.
Speaker 2: Until you get half the developers using ARM the other
Speaker 2: half using xAd six platforms.
Speaker 4: Yes, there's a whole another paradigm shift that we now
Speaker 4: have to think about, right, Well, I know, yeah, I
Speaker 4: know a lot of the Ruby gems do work on it,
Speaker 4: but there's a handful that don't. And I know the
Speaker 4: company I work with as actually we're investing actually looking
Speaker 4: for rubis to help make get all of those gems
Speaker 4: up to speed un armed because the price improvement, sorry,
Speaker 4: the performance and price improvement is really significant. So it's
Speaker 4: a it's a big boost.
Speaker 2: Yeah, I couldn't have said it better myself. I have
Speaker 2: a eight core mac Pro one hundred and ninety two
Speaker 2: gigs RAM thing is a monster. Then I have a
Speaker 2: thirteen inch MacBook PROILM one with sixteen gigs of RAM.
Speaker 2: You know, whatever it comes with. I can't tell a
Speaker 2: difference in performance on my day to day tasks. I
Speaker 2: really cannot tell the difference. There is a huge price
Speaker 2: tag difference. It's insane. So the ELM one, the whole
Speaker 2: ARM movement that Apple is doing, I think is amazing,
Speaker 2: and if they can keep it cost effective, then it's
Speaker 2: going to really make a huge difference in how we
Speaker 2: approach things, no.
Speaker 4: Doubt, one hundred percent agree. I really you know now
Speaker 4: that I'm a developer evangelist. I shifted from engineer too.
Speaker 4: I guess you could say I'm on the marketing side,
Speaker 4: so still an engineer at heart. But the phrase game
Speaker 4: changer gets overused so many times. When you go to conferences,
Speaker 4: you hear this is a game changer, that's a game changer.
Speaker 4: I think. I think the use of ARM, what we're
Speaker 4: talking about here, I think actually does fall into that category.
Speaker 4: I think it's a big shift and you're going to
Speaker 4: see a lot of energy put toward that, and I
Speaker 4: think it's really going to help things out. I mean,
Speaker 4: people complain about sometimes rails being slow. It's like, well,
Speaker 4: if you run it on a faster computer, that that's
Speaker 4: a really nice way to solve that problem. Certainly certainly
Speaker 4: cost effective there, it's a lot cheaper than the person
Speaker 4: hours that you might spend diving in, diving into that potentially.
Speaker 1: Yeah, I want to move us back toward micro service
Speaker 1: here services here for a minute, because I just remember
Speaker 1: the nightmares. I went, you're moving stuff to micro services
Speaker 1: back in the day, and I can kind of imagine
Speaker 1: scenarios that are somewhat obvious, right, I mean, you know,
Speaker 1: you can move your authorization right over to micro services
Speaker 1: and then you just you know, maybe do some permissions
Speaker 1: checks or you know, authority checks validate that somebody's actually
Speaker 1: who they say they are against their identity on the
Speaker 1: machine or on the other service, right, And so that's
Speaker 1: kind of an obvious one to me. But I remember
Speaker 1: we tried to split our app up into services, and
Speaker 1: things were pretty tightly coupled together. And it's because the
Speaker 1: concerns kind of blended from one thing to the next,
Speaker 1: right from one step to the next or stage to
Speaker 1: the next, as things move through the system, and so
Speaker 1: there really wasn't a clear cut, a clear place to cut.
Speaker 1: And so we when we picked one because it's like, oh, well,
Speaker 1: this is stage one and this is stage two, so
Speaker 1: we're just going to cut it between stage one and
Speaker 1: stage two. Well it turned out that stage one and
Speaker 1: stage two still have a lot in common, and so
Speaker 1: you know, there's not that clear delineation, and so it
Speaker 1: gave us problems. And you know, I'm thinking about some
Speaker 1: of the apps that I'm working on now and a
Speaker 1: lot of them have that same problem. And that's why
Speaker 1: this monolith idea works really nicely, right, is because all
Speaker 1: of those concerns that kind of span the entire app
Speaker 1: are all in there. So how do you start to
Speaker 1: really think about Okay, you know this is a good
Speaker 1: option for a micro service, and this maybe does belong
Speaker 1: in a monolith.
Speaker 4: Yeah, it's a great question. So you know, I mentioned
Speaker 4: that earlier. I wrote a book with the phrase best
Speaker 4: practices and a title, and I think I have a
Speaker 4: little bit different take on that now. I believe that
Speaker 4: the use of micro services what we've been talking about,
Speaker 4: is a great practice to do if it works for you,
Speaker 4: and it's probably you know, it's not a one one
Speaker 4: size fits all, So it's more of a concept that
Speaker 4: you can apply to your situation. If it's really hard
Speaker 4: to to untangle those concerns, you know, maybe maybe you
Speaker 4: just keep it in, keep it in that single app.
Speaker 4: Maybe it's not not worth doing, not worth the effort
Speaker 4: to break it out.
Speaker 2: So I basically have a general rule of thumb when
Speaker 2: it comes to micro services if this feature, you know.
Speaker 2: So let's give a real world example. Let's say if
Speaker 2: I'm in the business of PDFs and whether I'm a
Speaker 2: government or whomever, and I want to have the ability
Speaker 2: to take in a PDF and then have it automatically
Speaker 2: do the form fill out based on the parameters that
Speaker 2: are coming in. So this is a very useful feature
Speaker 2: for one of the applications that I'm developing within our
Speaker 2: same organization. This feature is also very useful for five
Speaker 2: other applications that we're developing. So because this feature can
Speaker 2: provide a lot of usefulness to these five different applications,
Speaker 2: and we can come to some kind of compromis or
Speaker 2: agreement on its API of how it should look. It
Speaker 2: should be taken a form post with a list of parameters.
Speaker 2: It should have an idea of a PDF that is
Speaker 2: stored on the database or wherever it's stored. Then we
Speaker 2: can have one codebase that serves five applications. So I
Speaker 2: think that's a good use case of a micro service.
Speaker 2: It does one thing, it does it really well, and
Speaker 2: it is highly reusable, not only in my application, but
Speaker 2: in multiple other applications.
Speaker 4: Yeah, that's a great example. And I think that if
Speaker 4: you've identified that as a needs used in more than
Speaker 4: three places, which is a good general rule for reuse,
Speaker 4: so you know you want to package that up and
Speaker 4: not repeat yourself across that group. So how do you
Speaker 4: deliver that capability to the other users of it or
Speaker 4: even reuse it yourself? And so you know, you could
Speaker 4: just point point the other teams or the other developers
Speaker 4: to the repo. You could build a gem package it
Speaker 4: that way, which is also a nice way to do it,
Speaker 4: or the route that you described. You could make it
Speaker 4: an API or a micro service and it is it's
Speaker 4: well defined and it is that that's a perfect use
Speaker 4: case for a micro service, I will say, Chuck, you
Speaker 4: also brought up the authorization. So those kind of you know,
Speaker 4: non functional concerns are prime candidates as well. They're easy
Speaker 4: to separate out from the rest of your application. It's
Speaker 4: where you get into the nitty gritty of the business
Speaker 4: logic or workflow where it becomes a little bit harder
Speaker 4: to do it. I will say, though, to try to
Speaker 4: tie some of these threads together. You mentioned earlier Dave
Speaker 4: that Netflix has thousands of these and really Aws does too.
Speaker 4: So one thing I realized that when I was there.
Speaker 4: You know, one of the best things that Amazon does
Speaker 4: is they make each team be essentially like its own
Speaker 4: startup company, so that that team can innovate as fast
Speaker 4: as they can and deliver value to customers. And then
Speaker 4: I also say, the worst thing that they do is
Speaker 4: that very same thing, because you have all of these
Speaker 4: teams not always marching to the same beat and kind
Speaker 4: of repeating some things are not always always going in
Speaker 4: the same direction, but all of these different web services are.
Speaker 4: It's not really Customers think about it as one infrastructure
Speaker 4: or platform that they're using, but it's really one hundred
Speaker 4: and fifty different services. I think the numbers actually higher
Speaker 4: probably now. And so when you're building one of those,
Speaker 4: you're using easily, you know, ten or twelve other ones
Speaker 4: in order to compose your application. So I worked on
Speaker 4: a security service. I helped build Resource Access Manager, and
Speaker 4: so you know, in terms of like monitoring and other
Speaker 4: kind of things, you know, we obviously we don't. We
Speaker 4: didn't build our own monitoring service. We use cloud watch
Speaker 4: for example, and authorization of course we use. We used
Speaker 4: I am identity access manager. So it's really those are
Speaker 4: good examples of large sets of services. You can think
Speaker 4: of them as micro services. Some are more coarse grained,
Speaker 4: but in order to build up these really large, really
Speaker 4: large platforms that can do amazing things that run run
Speaker 4: a majority of the Internet when you think about it,
Speaker 4: and so there's there's a lot of capability there. Again,
Speaker 4: it comes with the caveat Like we talked about before,
Speaker 4: those type of companies have, you know, armies of engineers
Speaker 4: who can work on all of these things. Most of
Speaker 4: us are not in a position where we have that
Speaker 4: many other teammates and teams to help us do this.
Speaker 4: So you kind of have to right size these design
Speaker 4: principles for the scenario, your scenario you're working on. But yeah,
Speaker 4: there is no one right answer. You always want to
Speaker 4: apply it to your situation.
Speaker 3: I guess.
Speaker 1: The other the other end of that right is how
Speaker 1: big does it have to be to warrant putting it
Speaker 1: into a micro service as opposed to putting it into
Speaker 1: a delayed job sidekick rescue worker, or just sticking it
Speaker 1: in like lib or app services or whatever, as just
Speaker 1: the library that just does a thing right and then
Speaker 1: just gets called out somewhere.
Speaker 4: Yeah, I would, So here's where we get into. I
Speaker 4: would evaluate the deployment or sorry, the operational aspect of
Speaker 4: it and see what you can get there. So, if
Speaker 4: it's a sidekick job, you're going to have a little
Speaker 4: less You have to make sure you build in the
Speaker 4: metrics and the visibility to see how that is behaving.
Speaker 4: If it's its own micro service, which you can, let's
Speaker 4: say it's in a container, I can observe that independently
Speaker 4: very easily. I can scale it separate from everything else.
Speaker 4: So if you let's say you have your web app
Speaker 4: and a sidekick process, so you're taking orders on the
Speaker 4: front end and Sidekick is doing some fulfillment on the
Speaker 4: back end. So if you make a change and let's
Speaker 4: say that the CPU spikes or you identify a memory
Speaker 4: leak or some other problem, you know it's not going
Speaker 4: to be immediately obvious. Well, was that one of the
Speaker 4: changes I went into the web app or was it
Speaker 4: the asynchronous job, And then what's the impact of that?
Speaker 4: The impact is much different, right because your focus, you
Speaker 4: should have a relentless focus on your customer. So if
Speaker 4: it's the web app, they can't take any orders. If
Speaker 4: it's the sidekick process. It's like, well, that's a little
Speaker 4: bit better. I can still accept orders and I'm going
Speaker 4: to hopefully get that business. I might just be a
Speaker 4: little delayed in getting the shipments out or processing whatever,
Speaker 4: whatever it is. So having to be its own if
Speaker 4: it's valuable like that, right, If I can get benefit
Speaker 4: from observing it and scaling it separately, then you're in
Speaker 4: a better spot. If you need to scale up that
Speaker 4: back end process, if it's doing more work, then you know,
Speaker 4: maybe it's nice to have it in a separate deployable unit.
Speaker 4: But those are the types of considerations that I would
Speaker 4: look at as opposed to, or in addition to, I
Speaker 4: should say, the separation of concerns and how easily how
Speaker 4: easy is it for me to make code changes if
Speaker 4: I need to innovate AD capabilities.
Speaker 2: Yeah, so I have a little story that I'll try
Speaker 2: to make tangible to this. So I've had a number
Speaker 2: of dogs growing up, and one of the dogs, you know,
Speaker 2: was a border collie. So the nature of the border
Speaker 2: collie is a hurting animal. And if we had installed
Speaker 2: an invisible fence around our yard, it really would have
Speaker 2: confused the dog because that dog is meant to be
Speaker 2: more free, and it would have hurt its nature essentially.
Speaker 2: So we got a chain link fence which was a physical,
Speaker 2: visible boundary around the yard. And I had another dog
Speaker 2: whom was not a hurting dog. They're more of a
Speaker 2: guard dog. So that dog wanted to be around me
Speaker 2: all the time. It was a rot Wilder Doberman mix
Speaker 2: which I named her Kitty, but that's a different story.
Speaker 2: And I could let that dog out of the yard,
Speaker 2: you know, into a open backyard and run free, and
Speaker 2: we never had to worry about her because she always
Speaker 2: quickly came right back to us because she wanted to
Speaker 2: be right there next to us. She wasn't interested in
Speaker 2: hunting or hurting. So the idea of in translating this
Speaker 2: back over to what we're talking about with micro services
Speaker 2: versus monoliths, I think that the monolith is more like
Speaker 2: that big open backyard without any boundaries. And if you're
Speaker 2: not careful, it's not a matter of if, but just
Speaker 2: a matter of when are you going to to have
Speaker 2: an accident or mistake on your hands because you have
Speaker 2: now gotten too much cross contamination within your application. You
Speaker 2: weren't careful with the boundaries and you broke a lot
Speaker 2: of single responsibility principles, and now things are too tightly
Speaker 2: coupled and intertwined in together, and you have a mess.
Speaker 2: Whereas the fenced in backyard is more like the micro services,
Speaker 2: where you are forced to stay within this confined area,
Speaker 2: which means you're forced to think about and write the
Speaker 2: single responsibility principles because you don't have access to the
Speaker 2: outside world beyond your gated fens. And I think that
Speaker 2: if we are talking about a single application, that its
Speaker 2: codebase is never reused anywhere else. So I think that
Speaker 2: we can train ourselves as developers to have more responsibility
Speaker 2: in how we are writing our code, to not introduce
Speaker 2: a lot of this cross contamination of logic which really
Speaker 2: should be separated out. And by doing that, like Chuck said,
Speaker 2: with the lib or app services or interactors, whatever kind
Speaker 2: of naming you want to call it, but these plain
Speaker 2: old Ruby objects where you're encapsulating and building these virtual
Speaker 2: fences around that bit of logic, then you're able to
Speaker 2: create the idea of the micro services without breaking up
Speaker 2: the majestic monolith.
Speaker 4: That's a great analogy for separation of concerns. I got
Speaker 4: to remember that one and use that in the future.
Speaker 4: The dogs in the fenced in backyard. I like that. Yep, yeah,
Speaker 4: I mean I think that you brought up a really
Speaker 4: good point. It's like, well, you know, we're all if
Speaker 4: we're all in the same backyard, you know, how long
Speaker 4: will it be until we all you know, cause problems
Speaker 4: We bump into each other trying to get our work done.
Speaker 4: You know, one person is cutting the grass in the
Speaker 4: backyard while the others are trying to play volleyball. It
Speaker 4: just doesn't work very well. And so, you know, we
Speaker 4: talked about actually like as it gets bigger, it can
Speaker 4: get more complicated. But you can look at it the
Speaker 4: other way that as you know, it's easy when you're
Speaker 4: getting started to have it all being you know, app
Speaker 4: and live, it's actually as you get bigger and bigger
Speaker 4: where it becomes more of a challenge because changing one
Speaker 4: thing has ramifications and unintended places, and that's really one
Speaker 4: of the one of the big challenges. There's a pretty
Speaker 4: nice tool that I've been working with or testing out
Speaker 4: called app land and its it's a it's open source,
Speaker 4: you can grab it and it gives you a nice
Speaker 4: visual map of the connections the call stacks and you
Speaker 4: can see how your components are related. You know, I
Speaker 4: always like to see I'd like to have a visual
Speaker 4: or mental model in my head of their requests coming
Speaker 4: in and how the route that they take through the
Speaker 4: controller and what objects they actually use. And this gives
Speaker 4: you a nice kind of visual representation of that. This
Speaker 4: was actually something that I thought about when you know,
Speaker 4: I first started doing Rails and Ruby, which I mentioned,
Speaker 4: you know, like six seven years ago. And when you
Speaker 4: do Ruby or sorry when you excuse me, when you
Speaker 4: do rails new it's interesting you actually get I think
Speaker 4: it's about fifty files with five hundred lines of code,
Speaker 4: give or take. And Rails isn't embarrassed about this either,
Speaker 4: because you can do bin rail stats and it'll tell
Speaker 4: you exactly how many files and lines of code there are.
Speaker 4: So that's a lot of code and a lot of
Speaker 4: files just to do a Hello World. Right. If I
Speaker 4: was going to compare that to no JS, for example,
Speaker 4: I think probably one file maybe what like five lines
Speaker 4: something like that. But that's there's also the positive aspect
Speaker 4: of it that it gives me. It prescribes a lot
Speaker 4: of things for me. I always if I know, if
Speaker 4: I want to find out where a controller action is.
Speaker 4: I know exactly where to look. If I want to
Speaker 4: find where the images are located, I already know. So
Speaker 4: it gives me a great framework to get started. It doesn't,
Speaker 4: you know, it's not going to stop you from dumping,
Speaker 4: from making your your helper's directory become a dumping ground
Speaker 4: for every everything known to man and having all kinds
Speaker 4: of all kinds of stuff in there. That's not going
Speaker 4: to prevent that. And that's where the backyard can get
Speaker 4: kind of messy. I will say the one having worked
Speaker 4: on a lot of different projects in different languages and technologies,
Speaker 4: it's nice, you know. It used to be that on
Speaker 4: every project you would have the infamous like string helper class,
Speaker 4: and so it's nice that we don't have to do
Speaker 4: that in Ruby because the string the string class is
Speaker 4: pretty rich and as most of what you need, so
Speaker 4: we don't we don't have to do with that. But
Speaker 4: you know, helper directories always things like that can get
Speaker 4: messy pretty quickly if you're not careful. My daughter has
Speaker 4: a multiese poodle, Peanut, and I'm pretty sure when I
Speaker 4: take Peanut out for a walk, if I took him
Speaker 4: off the leash. I'm pretty sure he would go running.
Speaker 4: I don't think he's the guard dog that that would
Speaker 4: stand by my side. He'd be you know, like down
Speaker 4: the road checking things out. That he's probably like, finally
Speaker 4: I get to go run around.
Speaker 3: Yeah. That's funny because when I was a kid, we
Speaker 3: had two dogs.
Speaker 1: We had a cocker Spaniel and you know, so she
Speaker 1: was kind of a little dog, and then we had
Speaker 1: a miniature Chihuahua and she was a littler dog, a
Speaker 1: much littler dog. She weighed about a pound and a half.
Speaker 1: Oh wow, Yeah, she was tiny, and we the cocker
Speaker 1: spaniel couldn't get out of the backyard, but she could
Speaker 1: dig holes deep enough for the chihuaha to get out
Speaker 1: of the backyard. And there was nothing we could do
Speaker 1: to stop it. And so and that, I guess taking
Speaker 1: that metaphor to the next level. That's the other thing
Speaker 1: that you find is if everybody, if you share the backyard,
Speaker 1: somebody's going to find a way to dig a hole
Speaker 1: to let people out.
Speaker 4: That's a great point. So years will always find a way.
Speaker 3: So now we're in a Jurassic Park.
Speaker 1: But anyway, Yeah, it's it's definitely interesting to think about
Speaker 1: But at the end of the day, I mean, we're
Speaker 1: we're just trying to solve problems, right. And it's it's
Speaker 1: interesting too because I keep having the conversation with my
Speaker 1: coworkers and it's you know, I shouldn't suggest this because
Speaker 1: this is work that I don't want to have to do,
Speaker 1: but this is probably the right solution to this problem.
Speaker 1: And you know that's what we're in it for, right,
Speaker 1: We're in it to solve these problems, right, And so
Speaker 1: sometimes it's going to be micro services is you know,
Speaker 1: a terrific way to solve the problem. And sometimes it's
Speaker 1: going to be, hey, you know, we need to keep
Speaker 1: all this stuff together so that it kind of all
Speaker 1: moves and works together in this way. And sometimes we're
Speaker 1: going to be in a situation where we just have
Speaker 1: to make a judgment call.
Speaker 3: And so I like that.
Speaker 1: That's where this conversation is gone, where it's hey, look,
Speaker 1: these are some of the trade offs that come in
Speaker 1: this way or that way, and these are some of
Speaker 1: the considerations you're going to wind to make in.
Speaker 4: Yeah, that's really that's really well said. These are different
Speaker 4: tools in the toolbox, and yeah, solve solving problems is
Speaker 4: one of the greatest parts about being, you know, an
Speaker 4: engineer and doing what we do probably closely followed by
Speaker 4: seeing our users and customers actually get to take advantage
Speaker 4: of these these creations that we out into the world.
Speaker 2: Yep, absolutely, because I mean, let's face it, if you
Speaker 2: have a really pro team that follows wonderful practices, they're
Speaker 2: very consistent and there's no hidden surprises, and if you
Speaker 2: create a monolith, then it's going to be very maintainable,
Speaker 2: it's going to be well tested and you're not going
Speaker 2: to have any problems. Take that in compared to a
Speaker 2: team that is not very well versed. They are not
Speaker 2: consistent and they're creating micro services. Now you have an
Speaker 2: application which consists of one hundred microsurfaces and each one
Speaker 2: is its own nightmare. So and it can go either way.
Speaker 2: You have a team that's great with micro services, they're
Speaker 2: great with practices, and everything is consistent and isolated in
Speaker 2: these micro services, and it's could be a great application.
Speaker 2: But then you have a team that's not as well
Speaker 2: versed and they are just creating an insane monolith that
Speaker 2: is just unmaintainable. So it's a healthy balance of choosing
Speaker 2: the right tool for the job and making sure that
Speaker 2: you have the team and budget to match, as well
Speaker 2: as the infrastructure budget to host, because as we said,
Speaker 2: there could be differences in which direction you go. So overall,
Speaker 2: I think that because I've worked primarily on Ruby on
Speaker 2: Rails applications, micro services doesn't really have a fit in
Speaker 2: my world because I think the convention over configuration that
Speaker 2: Rails his provided me, plus the practices that I have
Speaker 2: developed over the past ten twelve years, has really negated
Speaker 2: the need for micro services in my world. But that
Speaker 2: could be a different story for someone else where micro
Speaker 2: services is the answer for them.
Speaker 1: Yeah, I also just want to I should point out
Speaker 1: so the app that I work on primarily these days
Speaker 1: for my full time job, it was written to replace
Speaker 1: another app that was written in another framework, in another language,
Speaker 1: and essentially it was written very quickly by some very
Speaker 1: talented engineers. But it was written very quickly, and they
Speaker 1: threw a lot of best practices out the window just
Speaker 1: to get it out the door. And so we're dealing
Speaker 1: with those the fallout of that stuff right now. Right
Speaker 1: because we're now in the second year, we're coming back
Speaker 1: around to, you know, essentially another iteration of what this
Speaker 1: thing does, and you know, and so we're coming into Okay,
Speaker 1: we've got to deal with this, and we've got to
Speaker 1: do with this, we've got to deal with that, we've
Speaker 1: got to deal with you know, these other things. And
Speaker 1: it's you know, it's yeah, you know what Dave's saying.
Speaker 1: It's just not pretty. And it really does, in a
Speaker 1: lot of cases, come down to your discipline and your
Speaker 1: willingness to look at these problems and identify where these
Speaker 1: things are going to come up right, and so you know,
Speaker 1: whether or not you use one architecture or the other,
Speaker 1: whether or not you make these decisions one way or
Speaker 1: the other, what it really comes down to is your
Speaker 1: discipline in implementing them and approaching these problems in a
Speaker 1: way that is going to solve the problem in the
Speaker 1: long term. And RAILS does a lot of things that
Speaker 1: makes it really easy for you to approach this. From
Speaker 1: the majestic monolith, I kept saying beautiful monolith at the
Speaker 1: beginning because I couldn't remember the word that dhhused in
Speaker 1: his blog article. And I have the article up now
Speaker 1: in front of me, so I'll put on link in
Speaker 1: the show notes. But you know, and that's his approach
Speaker 1: and so that's the approach to the from rails. But
Speaker 1: as Darren pointed out, you know, there are a lot
Speaker 1: of things in there because it's built on rack that
Speaker 1: it does exceptionally well. That allows you to break it
Speaker 1: out into services if you need to. And so because
Speaker 1: of that, it makes it, you know, really versatile in
Speaker 1: your approach, and so you know, find the approach that
Speaker 1: works for you and then just be disciplined in the
Speaker 1: way that you approach it so that it does the
Speaker 1: work that you need it to do, solve the problem
Speaker 1: that you need to solve. And that's the that like,
Speaker 1: like Darren said, this is the really great part is
Speaker 1: that we get to go in and we get to
Speaker 1: figure out the pieces to the puzzle. It's like playing
Speaker 1: a video game, except at the end of the day
Speaker 1: it's not the prescribed path through the level. It's the Hey,
Speaker 1: at the end of the day, we got the problem
Speaker 1: solved and we get to do some really cool stuff
Speaker 1: along the way to figure it out.
Speaker 4: Yeah, those two points, those two points were spot on.
Speaker 4: Right at the end of the day, there's no there's
Speaker 4: no until AI advances to another level, maybe there's no
Speaker 4: replacement for the design and the discipline, Right, So you
Speaker 4: do that design upfront and it's like what's best for
Speaker 4: my situation, and then the discipline. I think that you know,
Speaker 4: even after you've agreed on the design, I think there's
Speaker 4: no substitute for those code reviews, right, Like, that's that's
Speaker 4: where you're really like, Okay, are we are we really
Speaker 4: doing what we said we were going to do? We
Speaker 4: are we following our guidelines? You know. That's how you
Speaker 4: make sure that you accomplish that goal and you don't
Speaker 4: end up kind of in a situation like you describe,
Speaker 4: where a lot of people find themselves with a code
Speaker 4: base that has a life of its own, its own personality,
Speaker 4: for whatever reason that it ended up being created that way. Right,
Speaker 4: there's always reasons that at the time that get applied,
Speaker 4: but there's just no substitute for those things. Yeah. I've
Speaker 4: worked previously. I worked in environments where we did not
Speaker 4: review every line of code, and then more recently I did,
Speaker 4: And it's hard to imagine not having code reviews for
Speaker 4: everything anymore.
Speaker 1: Yeah, So real quick, I'm going to throw out a
Speaker 1: couple of resources and then we'll get to picks. One
Speaker 1: is you mentioned machine learning and AI and I have
Speaker 1: to say, we have a machine learning podcast. You can
Speaker 1: go check it out at Adventures machine Learning. Just go
Speaker 1: to devchat dot tv click podcasts up at the top
Speaker 1: and it's right there Adventures and machine Learning. Or you
Speaker 1: can find it in your favorite podcast app. Just do
Speaker 1: it search Adventures in Machine Learning.
Speaker 3: You'll find it.
Speaker 1: It's got kind of a face and some artwork. Anyway,
Speaker 1: it looks really cool and I'm very proud of it.
Speaker 1: And yeah, one of the hosts, he's a really good
Speaker 1: looking guy. And yeah, Migael's pretty cool too. The other
Speaker 1: one that I'm going to throw out there, and you know,
Speaker 1: because we're talking about discipline and practices and things like that.
Speaker 1: I had a really terrific conversation with Bob Martin about
Speaker 1: clean craftsmanship and he talked about practices. Oh man, I'm
Speaker 1: gonna blow this so hard. Practices. There were three levels
Speaker 1: to it. The third one was ethics practicals. I think
Speaker 1: it was disciplines. Principles was the principles anyway, go listen
Speaker 1: to it because he breaks it down. And the first
Speaker 1: level was he talks about TDD pairing. You know those
Speaker 1: kinds of things where you know, like you're talking about
Speaker 1: the code reviews kind of falls underpairing, right, and then
Speaker 1: testing of some kind right under TDD, you know, and
Speaker 1: some of these other things where you're just doing these
Speaker 1: practices that get you to.
Speaker 3: Where you need to go.
Speaker 1: And then you have standards, right, That's what it was.
Speaker 1: It with standards, and so what are your code standards? Right,
Speaker 1: that make the code the kind of quality that you
Speaker 1: have to do. And then the ethics where you know,
Speaker 1: the kinds of things where it's and he has the
Speaker 1: programmer's oath is what he calls it, and we kind
Speaker 1: of talked through that.
Speaker 3: We have another.
Speaker 1: Episode where we talked about that on the Clean Coders podcast,
Speaker 1: But he talks about you know, hey, you know, am
Speaker 1: I making the code based better? Am I delivering for
Speaker 1: the company that's paying me for my time? Am I
Speaker 1: delivering code that meets the kind of standards? Am I
Speaker 1: improving my skills so that I can deliver for my team?
Speaker 1: And you know, things like that, and anyway, it was
Speaker 1: really really interesting conversation and that's the kind of thing
Speaker 1: that we really need to be talking about too, within
Speaker 1: our within our teams and with the people that we
Speaker 1: work with, because at the end of the day, it's
Speaker 1: not just Hey, here's the technology and the technical approach
Speaker 1: that we used to solve the problem, but it's yeah,
Speaker 1: what are we doing to make sure that it's the
Speaker 1: right solution to the right problem. What are we doing
Speaker 1: to make sure that the code meets the standards that
Speaker 1: we have for the kinds of solutions we deliver, and
Speaker 1: what kinds of things are we doing day to day
Speaker 1: in order to make sure that we are delivering for
Speaker 1: the company that we work for, delivering for the team
Speaker 1: we work with, delivering for the world at large, and
Speaker 1: things like that. So anyway, terrific conversation. I'll put both
Speaker 1: of those links in the show notes, and yeah, let's
Speaker 1: go ahead and new picks. I'm going to push it today. First, Dave,
Speaker 1: do you have some picks for us?
Speaker 2: Yeah? Sure, So my first pick is a pack tool
Speaker 2: Gecko Gauge. If you've ever had to work with hardyboard,
Speaker 2: which is the cement fiber boards that you put on
Speaker 2: the side of houses, then this tool is amazing. It
Speaker 2: allows you to just clamp onto the previous fiber board
Speaker 2: that you installed and then set the new one just
Speaker 2: right on top. It'll be completely leveled to the other one.
Speaker 2: It is a life saving tool for working with hardyboard.
Speaker 2: And the whole reason why I picked this up is
Speaker 2: because I'm building a shed underneath our deck and I'm
Speaker 2: now getting around to the part where I'm doing the
Speaker 2: sighting to make it look like the rest of the house.
Speaker 2: I was not going to be able to do this
Speaker 2: job without that tool. So it's amazing. And on the
Speaker 2: date of recording this podcast today is April first, i
Speaker 2: launched a new tutorial site. So I've been doing drift
Speaker 2: and Ruby for many, many years, over two hundred eighty
Speaker 2: episodes I've recorded on Ruby and Ruby on rails, and
Speaker 2: so today I've launched a new training site and that
Speaker 2: is drifting Cobal. So you can go to driftingcobyl dot
Speaker 2: com and you'll see that it's a completely satire side
Speaker 2: for April first, but hey, if it picks up one subscriber,
Speaker 2: that's like ten percent of the entire Cobalt user base,
Speaker 2: so I'd say that's when.
Speaker 4: Wow, that's amazing. I actually did Cobal when I first
Speaker 4: started programming dating myself again, so this is great to see.
Speaker 3: Nice, very cool. I'm gonna have to is that a
Speaker 3: punch card?
Speaker 2: It is nice, It's not a real punch card. The
Speaker 2: real punch cards were more like the this is.
Speaker 4: This looks like a copy book description almost Yeah, your
Speaker 4: data formats.
Speaker 3: And oh I'm tweeting it right now.
Speaker 4: It is a good It is a good call out
Speaker 4: that we are recording this on April first. When you
Speaker 4: all asked me to be a guest on the podcast,
Speaker 4: I wasn't sure if you were joking or serious.
Speaker 3: Hey, you scheduled it not us fair enough?
Speaker 4: Fair enough?
Speaker 1: Yeah, all right, I've got a couple of picks I'm
Speaker 1: gonna throw out there. The first pick that I have
Speaker 1: is I've been using this tool I'm really liking. It
Speaker 1: is called click up now. If you have used no
Speaker 1: notion dot so I've picked it on the show before.
Speaker 1: Notion is kind of an all in one how do
Speaker 1: I put it? It's supposed to be kind of a
Speaker 1: wiki slash, trellos slash, to do list slash anyway, it
Speaker 1: does not have any kind of automation, and it doesn't
Speaker 1: integrate with Zapier, and so I quit using it eventually
Speaker 1: because I just couldn't.
Speaker 3: I couldn't do with it what I wanted to do.
Speaker 4: Right.
Speaker 1: Well, clickup has all that stuff built in and what
Speaker 1: it doesn't have built in it actually integrates with Zapier.
Speaker 1: So I'm really really loving this tool, and so I'm
Speaker 1: actually moving as many of the workflows for.
Speaker 3: Devchat dot tv over to it as I can.
Speaker 1: A lot of the stuffs still on Trello, and that's
Speaker 1: where I wound up moving a lot of this stuff too,
Speaker 1: so it's going to take some time to move it over.
Speaker 1: But I am really really looking forward to some of
Speaker 1: this stuff. I can actually include some of the other
Speaker 1: folks from dev chat dot tv on it, and so
Speaker 1: I'm looking at instead of for example, we have some
Speaker 1: automation that's built into Zappier that's supposed to like pick
Speaker 1: things up and send out a calendar invite and set
Speaker 1: up a Google doc and do all this stuff. And
Speaker 1: I'm hoping that I can move all of that into
Speaker 1: clickup and then just invite our podcast guests as guests
Speaker 1: on the test. That's the only part of it. I
Speaker 1: can't guarantee what'll work because I haven't double checked on that,
Speaker 1: But for the hosts and everybody else, I can actually
Speaker 1: go in and do that, and I'm hoping to be
Speaker 1: able to automate all of that stuff so that then
Speaker 1: it comes back after the episode and says, because we
Speaker 1: manually have to follow up, Hey, can we get a
Speaker 1: description for the episode and a title for the episode?
Speaker 1: And because I'm not on all the shows, and so
Speaker 1: I'm kind of the backup on the shows that I
Speaker 1: show up for. But if I'm sick or if I'm
Speaker 1: just not on the show like Adventures in dot Net,
Speaker 1: I'm practically useless on that show anyway, Right, I can
Speaker 1: kind of make it up and go look up the terms.
Speaker 1: I don't know, but realist, right, if they're talking about
Speaker 1: like some deep library NC SHARP, it's like, okay, what
Speaker 1: is this thing?
Speaker 4: Right?
Speaker 3: And I have to go do some research.
Speaker 1: So that's what I'm looking at doing, is just automating
Speaker 1: the crap out of that. And so I'm pretty excited
Speaker 1: about that and working through it.
Speaker 3: But if it lets me automate all of that stuff,
Speaker 3: I'm going to be one happy dude.
Speaker 1: And so I'm going to pick that. The other thing
Speaker 1: that I am also going to pick is dev influencers.
Speaker 1: So dev influencers dot com. You've heard me talk about
Speaker 1: dev heroes, that's now dev influencers. So if you're looking
Speaker 1: at kind of that next stage, or if you're in
Speaker 1: a position like Darren, where you're a developer, evangelist, or
Speaker 1: you're trying to you know, gain some kind of audience,
Speaker 1: you know, where you're trying to get noticed. I'm putting
Speaker 1: together basically a coaching program and I currently have five
Speaker 1: people in there where I'm coaching them every week on Okay,
Speaker 1: here's how you build an audience. I'm focused on podcasts,
Speaker 1: So here's how you build an audience. Here's how you
Speaker 1: build your podcast. Here's how you get people to listen
Speaker 1: to it, Here's how you grow it. And then from
Speaker 1: there it's here's how you build it into Some people
Speaker 1: want to do speaking, some people want to teach live training,
Speaker 1: some people want to do courses.
Speaker 3: Some people want to do.
Speaker 1: I mean, you know, there are all these options. Build
Speaker 1: their freelancing practice, get a better job. All of those
Speaker 1: things are things that I have done out of podcasting
Speaker 1: while I'm working on the course. But all the other
Speaker 1: things are things.
Speaker 3: That I've done out of it.
Speaker 1: Right, I have a book that I've written that I've
Speaker 1: sold off to the back of the podcast, and so
Speaker 1: if that's something you're interested and you can go check
Speaker 1: it out. But if you want a podcast about it,
Speaker 1: I'm putting that out too, So go check it out
Speaker 1: dev influencers dot Com slash podcast and you can check
Speaker 1: that out there. You can also go to dev influencers
Speaker 1: dot com slash apply and you'll put your email and
Speaker 1: name in. And that's just so that some people, for
Speaker 1: whatever reason, they hit the thing on their phone, the application,
Speaker 1: and then for whatever reason they don't get the information in.
Speaker 1: That's so that I can just remind them, hey, look, yah,
Speaker 1: filled it out. Can you come back right? And then
Speaker 1: I'm planning on sending some emails out and some other stuff,
Speaker 1: putting some other stuff together there. But yeah, dev influencers
Speaker 1: dot Com that's where all that stuff's going to be
Speaker 1: for the podcast, and I'm going to be talking about
Speaker 1: how to advance your career. A lot of people they
Speaker 1: get stuck at senior developer, that's the other thing, and
Speaker 1: they're like, I don't want to be a manager. I
Speaker 1: don't really want to go architecture or whatever. I want
Speaker 1: to keep writing code and this is a way you
Speaker 1: can do that. So anyway, dev influencers dot Com. That's
Speaker 1: kind of my thing. And that's not an April Fool's joke. Darren,
Speaker 1: Do you have some picks for us.
Speaker 4: Yeah, well, I'm going to go ahead and mention if
Speaker 4: you like Ruby and rails and you like the getting
Speaker 4: those benefits of containers that I talked about, definitely check
Speaker 4: out engine yard containers. That's our the next generation platform.
Speaker 4: You can go to engine yard dot com. You can
Speaker 4: also on that site go under resources on the blog.
Speaker 4: You can check out my Ruby Unbundled blog where we
Speaker 4: talk about the different architecture concepts and and other cool
Speaker 4: things that I find fascinating about Ruby. But yeah, so
Speaker 4: engine Yard containers is a great way to quickly deploy
Speaker 4: those Ruby apps, scale them up, and get some of
Speaker 4: those observability and other benefits we talked about. Am I
Speaker 4: allowed to do that for a pick? Is that okay?
Speaker 3: Absolutely?
Speaker 1: We usually ask you to at the end where people
Speaker 1: can find you, So that's that does help.
Speaker 4: I'm ahead of the game, yep, I would. I would
Speaker 4: throw in mentioned the other app Land is a really
Speaker 4: nice way to figure out what's going on with your
Speaker 4: codebase as well. I would throw that out there as
Speaker 4: my other pick they have. I think app map is
Speaker 4: actually the gem. App Land is a site if you
Speaker 4: want to share those across different users on your project.
Speaker 3: Awesome. All right.
Speaker 1: Well, and then I'm assuming you're also on Twitter and facebo, Facebook, Twitter,
Speaker 1: and GitHub.
Speaker 4: I am at Darren Bramer d A R R E
Speaker 4: N b r O E M M E R. I
Speaker 4: probably need to get a better Twitter handle, don't I
Speaker 4: that's too complicated, but it is my name, so you can.
Speaker 4: You can find me there. And on GitHub, I have
Speaker 4: my old user ID, just letter D and then the
Speaker 4: first seven letters of my last name, D Bromine, so
Speaker 4: that's me on GitHub.
Speaker 1: All right, cool, all right, well, thank you for coming.
Speaker 1: This was really really fun. Yeah, thanks you so much
Speaker 1: for having me. This was great.
Speaker 3: Yeah, it's fun to argue about architecture, right.
Speaker 4: I love it. I love it.
Speaker 3: This is what it's all about, all right, folks. Well
Speaker 3: until next week, Max out