Architectures and Microservices with Darren Broemmer - RUBY 657

so I've done all types of engineering managed teams. I decided I wanted to go back get hands on keyboard. After doing that, went to Amazon Web Services, had a great time working there, learned a whole lot, had a lot of fun, met a lot of great people, and then wanted to get more into kind of combined the two things I really really enjoy, so the technology obviously,

but also communications. And so now I kind of kind of went and switched gears of now the developer evangelist for engine Yard, and we have platforms of service tools. But I get to do my two favorite things, which are play with technology and share that with people, write about it and talk about it.

going to come out in a few weeks. But it's just interesting because people are talking about this and how to break up application logic and stuff like that, and of course in RAILS we all talked about the beautiful monolith and you know how that all kind of comes together to put it all in one app. And so, yeah, I'm kind of interested because I don't know that I necessarily got the breakdown on where you come down on this.

And I remember early in my career, like soa service oriented architecture was a big thing, and I think I gave a whole bunch of talks and gave a whole bunch of bad advice because it was the cool thing to do, and I was really in love with the idea.

But you know, been built a few apps and took it way too far and it was like, you know a lot of this stuff really does belong in its own app, and then some of this stuff it started okay, some of this stuff belongs in workers and some of this stuff actually, you know, may belong in its own service,

you know, micro service. And so you know, I kind of have gone back and forth as to how much you want to peel off into different parts, and so I'm kind of curious where you come down as far as Okay, what do I break off into micro services? What part do I keep in the monolith? What part do I you know, and how do I break that up? And then I also saw some stuff about containerization, so we can I guess dive into that next. But yeah, how do how do microft services kind of fit into Ruby these days?

of indirection everywhere. So we need to make choices. I say that because every time you add a layer of indirection, there's it's not free. There there's a there's a cost to it. Right. We can't optimize to be able to change every aspect of the application. You know. For example, I've been on a number of projects over my career.

You know, the team would be, well, we need to abstract this and that so that if we want to swap out the database later on, we can This is maybe a little less relevant now, but I think the example still holds, and so there was effort spin into that. Now, how many of those projects ever actually swapped out databases?

You know, I can think of maybe one that went from a relational database to a no sequel, and they would if they had to make broader changes anyway, So you need to you need to think about where can I decompose my logic into reusable bits. And when you think about the basic rails architecture model view controller, generally speaking, you try to push that logic down in that if you think about it as a layer down as far as you can. You know, validations you'll always need to

do before you persist to the database. Yeah, put it in the in the model class. But it becomes very tough when you think about this. You know, there's lots of best practice and things about where to put quote unquote business logic, and in my experience that often ends up coming back to the service level or in rails, you know the equivalent of a rail's action a controller method. So if I'm a you want your code to mirror the real world as closely as possible, and I was

you know, you mentioned earlier. I've probably given bad advice in my career in the past too. I used to be huge enthusiast of object oriented and while I think it's still valuable and has its place, I think in terms of decomposition, if you want to mirror the real world. If I'm a customer, I don't think of objects and entities. So let's say I'm going to go online to pay my credit card bill. I don't think about that in terms of, well, there's an account object and a vendor

and a payment behavior. I think about that of I'm going to go pay my bill. You know, it's it's an action I take, something I do. And so you can try to push logic further down this stack, but usually it ends up kind of bubbling back up to this service layer because those are encapsulated units of work. Now paying your paying your bill that now I personally wouldn't do this, But let's say let's say I was late on paying my bill, so I'm going to incur

a fee. So that's probably another service to calculate what the late fee is based on when I submit it. All of that so you can see you can see that kind of breakdown, and so reusing those services. And actually, you know, this almost gets back to like functional programming. It's funny how things kind of come full circle every every so often. But to me, the service level is the easiest way to decompose and be close to how

you mirror the real world. And if you can do that, if you can model it closer, you're going to be you're going to be better off in the long run when you need to make make changes. So now segue that into micro service because microservice often has the connotation of being a separate physical deployment. So there's different steps you can take to migrate this. Right, So you mentioned the beautiful monolith. I might have tons of code all

sitting there. It's in one deployable one deployable unit. You know, Rome's not built in a day. I can't do all of this at once. So you know, one of the articles I wrote that you reference was really just well, how do I take that first step? How do I go from the beautiful modelith to whatever my target architecture is, whatever your favored decomposition model is. So the beautiful thing. One really nice thing about rails is I think it helps you out here. So even in my existing code

base a controller action. Let's say you're using rack as you're middleware. That controller action is actually a wreck its own RACK application. So in the rack up file, rather than just doing rails application new, you can actually just point it directly to that controller action. So now you can deploy that as a deployable unit. It's going to use the same code base, but from a logical standpoint, I've separated that out from the rest of the system.

I can begin to reason about it more, think about what changes when, how do I reuse things? And then just to tease the topic a little bit, just to throw the container bit out there so it's an easier migration then to make it a separate deployable unit because that same image, that same codebase, I'm just going to have a different rackup file that I use for each of those. I can deploy those separately, I can scale

them independently, I can observe them. See you know how they behave If one if the CPU goes off, the rails on one of them is going to be easier to identify where the problem was. So you don't get those kind of advantages until you actually make them true micro services and you get that observability, but there's a lot of benefits when you start to go down that road, and rails I think helps. Rails gives you tools to help do that incrementally. So that's kind of an overview

of where I'm at. I don't I don't think there's one. There's certainly not a one size fits all, but to the extent that you can go with micro services to break that out from a logical design perspective, and then the actual deployment get the observability, scalability independence. I think there's a lot of benefit there.

new database within a server. So if we're running postgrads, we have one instance of postgrads or a cluster, and then we have a new database for this micro service and that microservice only communicates to the one database or do they all share the same global database.

segregating those and making those their own deployable units. You know, you're still going to have some potential level of contention because you've got different apps talking to the same database, and so you know one could have one could certainly impact the other. You can still have a noisy neighbor

situation there. But as you migrate over time, if you can decompose your larger architecture into those discrete topic areas where you can have different databases, then you get a cleaner isolation, and that typically takes folks a lot longer to do. And you can also end up in the spot well where I need I need data from from both places, and you can end up getting into performance issues because you get you know, pretty chatty between these services.

So so it's not it's not with it's not a panacea for sure, but I think to the extent that teams can start thinking in that direction and trying to find those what are the what are the good isolation boundaries to use? And again there is it's not a black and white topic, but there's no crystal clear answer, but I think there's over overall if you look at

how do I make changes right? Because in today's economy, you know, with the pandemic and people being at home, like we were already essentially a digital economy, it's almost entirely that way now. So you know, we're all forced to innovate so much faster, you know, deploy We were already deploying continuously, and now we want to do it even more. So if we don't do it fast enough, someone else is going to copy our business model, We're going to we're going to lose lose customers we could have.

So there's so much pressure to get features out there faster, and so again it's you know, you can't optimize for everything, but it's thinking about well, what is going to benefit me to isolate where I may want to be able to innovate faster move separate from the other aspects of the code. One problem that and even at Amazon our teams ran into this, especially some of the bigger services, where you really want to get a bug fix out

or some feature out. But if you're all in the same if it's all in the same kitten kaboodle, and you've got an issue that pops up with one of the other changes, you got to roll that whole thing back because at the end of the day, you can't have impact ongoing impact to your customers. And so that is something that I think really hurts teams their velocity when you've got to make sure that these twelve or twenty or however many features are all working perfectly in

order to get all of them out the door. So rather than an all or nothing, micro services really help you there. So you wouldn't isolate everything, but the areas where you know you're going to have a focus on, or you can predict, or you already know that are important to your customers, that's where you may want to think about it.

But that then that positions you so that when you do move it out to a service, you can swap that out and it's and it's less of a problem in terms of the domains I like, I personally like having the different subdomains part of that. I guess the product that I work with, Engineer facilitates this pretty nicely, where each of your apps within the same application just

get different subdomains. But there's obviously different ways that you can do it, and you don't actually you know, of course you don't need to split that out because you could just use different URL paths to accomplish a similar goal. But having the if you get it into containers and you can segregate, then you get those benefits of the physical deployment also. So to me, I would keep I prefer to try to keep it simple. You you know,

certainly there there's a couple different choices there. I mean I would probably if you can't avoid putting messaging layers in between, you know that if you can keep it simple, rest calls, you're you know, unless you need to do something different, I'd probably would advocate for that. You know, keep it as simple as possible, but no simpler. But there's also other tools and frameworks that help you do that. I haven't worked with it in detail, AWSS Service Mesh,

which helps you orchestrate all of these micro services. So there are there are things out there that will that will help you manage all of this, and probably those are worth it if you really get into large numbers, if you really your if your enterprise is you know, truly bought in and you're and you're going across many different departments in many different organizations. That's probably when you when you look at something like that.

a vast amount of capability as well. I think for small and medium sized business, you're looking at a different category and a different type of architecture, and it would probably not be good if you got into those numbers. I will say, on the infrastructure cost point that you brought up, I think that would be true on if

you're on instances or virtual machines. However, containers are very efficient at this You can put a lot more container processes on the underlying hardware, and you can you also get a lot of those other benefits that I that I mentioned. So I don't know that the infrastructure cost would be quite as bad as you as you think

it is, because the container processes are pretty lightweight. They can start up in milliseconds as opposed to you know, like an EC two instance probably takes like between thirty and sixty seconds to start up, whereas a container, let's say it, let's round it off to a second. So you can scale those up and down really really quickly, and you can pack a lot more onto a physical cluster as well. So I don't know if that would

be as much of an issue. But on the on the complexity front, Tim, I agree, there's some point where it becomes unmanageable. Yeah.

database that's really all the application needs. But because you have scaled it up to fifty or one hundred micro services, you're not going to be able to connect to that same database instance with the lower tier plan because the number of max connections that's available on those various plans, you would have to either spin up multiple database servers, in which case you incur scaling costs there, or have one really large database server where you have multiple databases

within there, and then you still incur a higher cost just for that max number of connections. Now, AWS may have something different now where you can allow more connections, but each micro service would need at least its one own dedicated connection to the database instance.

too salesy, but we do. The company EngineYard also has a scale arc product which is a database proxy, which is also a nice way to actually get the three tier architecture independence actually separate out your application tier from your database by connecting to the proxy and then it can talk to all of these other databases make them look like different connections, do caching, intelligent caching, and security controls for you. Again, if you get into larger number

of databases, that might be something that's that's helpful. But yeah, packing multiple database schemas on the same you know, RDS cluster is actually pretty pretty good strategy in a lot of cases unless you have a really high volume er, a really large sized database.

So I'm really with you on there with using doctor containers and stuff like that, because I think that's the proper way to do auto scaling because you get instant reaction to your users instead of having to wait, Okay, we're at a fifty percent usage load across all our vms. We need to hurry up and add more servers, all automatically, of course, But then fifteen minutes later the server's provision and now it's ready. Well, that traffic's all said and done.

it's actually pretty nice for development as well. So developing with containers really helps cut down on how many times, how much time in my career have I spent getting my workstation, my development environment set up the way that I want it, and you know, managing those things. So using containers for development is really nice for that. There's also some really nice tooling to help out there as well,

so we offer dev spaces. There's also an open source gipod where you can with a single click bring up the online ide. It's running based on the container that you define, and you can also do some simple automation, so for example, you can have it on startup, do

your bundle, install, start your rail server. It opens up a preview window inside of your online ide, which is based roughly it's based roughly on vs code, so you can use those extensions as well, so, yeah, so you get benefits from containers, not just in the deployment, but I think in the development as well, and you know, hopefully never have to hear the phrase works on my machine. Again. That helps to alleviate some of those issues.

tag difference. It's insane. So the ELM one, the whole ARM movement that Apple is doing, I think is amazing, and if they can keep it cost effective, then it's going to really make a huge difference in how we approach things, no.

I think it's a big shift and you're going to see a lot of energy put toward that, and I think it's really going to help things out. I mean, people complain about sometimes rails being slow. It's like, well, if you run it on a faster computer, that that's a really nice way to solve that problem. Certainly certainly cost effective there, it's a lot cheaper than the person hours that you might spend diving in, diving into that potentially.

the nightmares. I went, you're moving stuff to micro services back in the day, and I can kind of imagine scenarios that are somewhat obvious, right, I mean, you know, you can move your authorization right over to micro services and then you just you know, maybe do some permissions checks or you know, authority checks validate that somebody's actually who they say they are against their identity on the machine or on the other service, right, And so that's

kind of an obvious one to me. But I remember we tried to split our app up into services, and things were pretty tightly coupled together. And it's because the concerns kind of blended from one thing to the next, right from one step to the next or stage to the next, as things move through the system, and so there really wasn't a clear cut, a clear place to cut.

And so we when we picked one because it's like, oh, well, this is stage one and this is stage two, so we're just going to cut it between stage one and stage two. Well it turned out that stage one and stage two still have a lot in common, and so you know, there's not that clear delineation, and so it gave us problems. And you know, I'm thinking about some of the apps that I'm working on now and a

lot of them have that same problem. And that's why this monolith idea works really nicely, right, is because all of those concerns that kind of span the entire app are all in there. So how do you start to really think about Okay, you know this is a good option for a micro service, and this maybe does belong in a monolith.

you can apply to your situation. If it's really hard to to untangle those concerns, you know, maybe maybe you just keep it in, keep it in that single app. Maybe it's not not worth doing, not worth the effort to break it out.

same organization. This feature is also very useful for five other applications that we're developing. So because this feature can provide a lot of usefulness to these five different applications, and we can come to some kind of compromis or agreement on its API of how it should look. It should be taken a form post with a list of parameters. It should have an idea of a PDF that is stored on the database or wherever it's stored. Then we

can have one codebase that serves five applications. So I think that's a good use case of a micro service. It does one thing, it does it really well, and it is highly reusable, not only in my application, but in multiple other applications.

to the repo. You could build a gem package it that way, which is also a nice way to do it, or the route that you described. You could make it an API or a micro service and it is it's well defined and it is that that's a perfect use case for a micro service, I will say, Chuck, you also brought up the authorization. So those kind of you know, non functional concerns are prime candidates as well. They're easy

to separate out from the rest of your application. It's where you get into the nitty gritty of the business logic or workflow where it becomes a little bit harder to do it. I will say, though, to try to tie some of these threads together. You mentioned earlier Dave that Netflix has thousands of these and really Aws does too. So one thing I realized that when I was there.

You know, one of the best things that Amazon does is they make each team be essentially like its own startup company, so that that team can innovate as fast as they can and deliver value to customers. And then I also say, the worst thing that they do is that very same thing, because you have all of these teams not always marching to the same beat and kind of repeating some things are not always always going in the same direction, but all of these different web services are.

It's not really Customers think about it as one infrastructure or platform that they're using, but it's really one hundred and fifty different services. I think the numbers actually higher probably now. And so when you're building one of those, you're using easily, you know, ten or twelve other ones in order to compose your application. So I worked on a security service. I helped build Resource Access Manager, and so you know, in terms of like monitoring and other

kind of things, you know, we obviously we don't. We didn't build our own monitoring service. We use cloud watch for example, and authorization of course we use. We used I am identity access manager. So it's really those are good examples of large sets of services. You can think of them as micro services. Some are more coarse grained, but in order to build up these really large, really large platforms that can do amazing things that run run a majority of the Internet when you think about it,

and so there's there's a lot of capability there. Again, it comes with the caveat Like we talked about before, those type of companies have, you know, armies of engineers who can work on all of these things. Most of us are not in a position where we have that many other teammates and teams to help us do this. So you kind of have to right size these design principles for the scenario, your scenario you're working on. But yeah,

there is no one right answer. You always want to apply it to your situation.

So if you let's say you have your web app and a sidekick process, so you're taking orders on the front end and Sidekick is doing some fulfillment on the back end. So if you make a change and let's say that the CPU spikes or you identify a memory leak or some other problem, you know it's not going to be immediately obvious. Well, was that one of the changes I went into the web app or was it the asynchronous job, And then what's the impact of that?

The impact is much different, right because your focus, you should have a relentless focus on your customer. So if it's the web app, they can't take any orders. If it's the sidekick process. It's like, well, that's a little bit better. I can still accept orders and I'm going to hopefully get that business. I might just be a little delayed in getting the shipments out or processing whatever,

whatever it is. So having to be its own if it's valuable like that, right, If I can get benefit from observing it and scaling it separately, then you're in a better spot. If you need to scale up that back end process, if it's doing more work, then you know, maybe it's nice to have it in a separate deployable unit.

But those are the types of considerations that I would look at as opposed to, or in addition to, I should say, the separation of concerns and how easily how easy is it for me to make code changes if I need to innovate AD capabilities.

visible boundary around the yard. And I had another dog whom was not a hurting dog. They're more of a guard dog. So that dog wanted to be around me all the time. It was a rot Wilder Doberman mix which I named her Kitty, but that's a different story. And I could let that dog out of the yard, you know, into a open backyard and run free, and we never had to worry about her because she always quickly came right back to us because she wanted to be right there next to us. She wasn't interested in

hunting or hurting. So the idea of in translating this back over to what we're talking about with micro services versus monoliths, I think that the monolith is more like that big open backyard without any boundaries. And if you're not careful, it's not a matter of if, but just a matter of when are you going to to have an accident or mistake on your hands because you have

now gotten too much cross contamination within your application. You weren't careful with the boundaries and you broke a lot of single responsibility principles, and now things are too tightly coupled and intertwined in together, and you have a mess. Whereas the fenced in backyard is more like the micro services, where you are forced to stay within this confined area, which means you're forced to think about and write the single responsibility principles because you don't have access to the

outside world beyond your gated fens. And I think that if we are talking about a single application, that its codebase is never reused anywhere else. So I think that we can train ourselves as developers to have more responsibility in how we are writing our code, to not introduce a lot of this cross contamination of logic which really

should be separated out. And by doing that, like Chuck said, with the lib or app services or interactors, whatever kind of naming you want to call it, but these plain old Ruby objects where you're encapsulating and building these virtual fences around that bit of logic, then you're able to create the idea of the micro services without breaking up the majestic monolith.

backyard while the others are trying to play volleyball. It just doesn't work very well. And so, you know, we talked about actually like as it gets bigger, it can get more complicated. But you can look at it the other way that as you know, it's easy when you're getting started to have it all being you know, app and live, it's actually as you get bigger and bigger where it becomes more of a challenge because changing one thing has ramifications and unintended places, and that's really one

of the one of the big challenges. There's a pretty nice tool that I've been working with or testing out called app land and its it's a it's open source, you can grab it and it gives you a nice visual map of the connections the call stacks and you can see how your components are related. You know, I always like to see I'd like to have a visual or mental model in my head of their requests coming in and how the route that they take through the

controller and what objects they actually use. And this gives you a nice kind of visual representation of that. This was actually something that I thought about when you know, I first started doing Rails and Ruby, which I mentioned, you know, like six seven years ago. And when you do Ruby or sorry when you excuse me, when you do rails new it's interesting you actually get I think it's about fifty files with five hundred lines of code,

give or take. And Rails isn't embarrassed about this either, because you can do bin rail stats and it'll tell you exactly how many files and lines of code there are. So that's a lot of code and a lot of files just to do a Hello World. Right. If I was going to compare that to no JS, for example, I think probably one file maybe what like five lines something like that. But that's there's also the positive aspect of it that it gives me. It prescribes a lot

of things for me. I always if I know, if I want to find out where a controller action is. I know exactly where to look. If I want to find where the images are located, I already know. So it gives me a great framework to get started. It doesn't, you know, it's not going to stop you from dumping, from making your your helper's directory become a dumping ground for every everything known to man and having all kinds of all kinds of stuff in there. That's not going

to prevent that. And that's where the backyard can get kind of messy. I will say the one having worked on a lot of different projects in different languages and technologies, it's nice, you know. It used to be that on every project you would have the infamous like string helper class, and so it's nice that we don't have to do that in Ruby because the string the string class is pretty rich and as most of what you need, so

we don't we don't have to do with that. But you know, helper directories always things like that can get messy pretty quickly if you're not careful. My daughter has a multiese poodle, Peanut, and I'm pretty sure when I take Peanut out for a walk, if I took him off the leash. I'm pretty sure he would go running. I don't think he's the guard dog that that would stand by my side. He'd be you know, like down the road checking things out. That he's probably like, finally I get to go run around.

that metaphor to the next level. That's the other thing that you find is if everybody, if you share the backyard, somebody's going to find a way to dig a hole to let people out.

And you know that's what we're in it for, right, We're in it to solve these problems, right, And so sometimes it's going to be micro services is you know, a terrific way to solve the problem. And sometimes it's going to be, hey, you know, we need to keep all this stuff together so that it kind of all moves and works together in this way. And sometimes we're going to be in a situation where we just have to make a judgment call.

consistent and they're creating micro services. Now you have an application which consists of one hundred microsurfaces and each one is its own nightmare. So and it can go either way. You have a team that's great with micro services, they're great with practices, and everything is consistent and isolated in these micro services, and it's could be a great application. But then you have a team that's not as well versed and they are just creating an insane monolith that

is just unmaintainable. So it's a healthy balance of choosing the right tool for the job and making sure that you have the team and budget to match, as well as the infrastructure budget to host, because as we said,

there could be differences in which direction you go. So overall, I think that because I've worked primarily on Ruby on Rails applications, micro services doesn't really have a fit in my world because I think the convention over configuration that Rails his provided me, plus the practices that I have developed over the past ten twelve years, has really negated

the need for micro services in my world. But that could be a different story for someone else where micro services is the answer for them.

with those the fallout of that stuff right now. Right because we're now in the second year, we're coming back around to, you know, essentially another iteration of what this thing does, and you know, and so we're coming into Okay, we've got to deal with this, and we've got to do with this, we've got to deal with that, we've got to deal with you know, these other things. And it's you know, it's yeah, you know what Dave's saying.

It's just not pretty. And it really does, in a lot of cases, come down to your discipline and your willingness to look at these problems and identify where these things are going to come up right, and so you know, whether or not you use one architecture or the other, whether or not you make these decisions one way or the other, what it really comes down to is your discipline in implementing them and approaching these problems in a way that is going to solve the problem in the

long term. And RAILS does a lot of things that makes it really easy for you to approach this. From the majestic monolith, I kept saying beautiful monolith at the beginning because I couldn't remember the word that dhhused in his blog article. And I have the article up now in front of me, so I'll put on link in the show notes. But you know, and that's his approach

and so that's the approach to the from rails. But as Darren pointed out, you know, there are a lot of things in there because it's built on rack that it does exceptionally well. That allows you to break it

out into services if you need to. And so because of that, it makes it, you know, really versatile in your approach, and so you know, find the approach that works for you and then just be disciplined in the way that you approach it so that it does the work that you need it to do, solve the problem that you need to solve. And that's the that like, like Darren said, this is the really great part is that we get to go in and we get to

figure out the pieces to the puzzle. It's like playing a video game, except at the end of the day it's not the prescribed path through the level. It's the Hey, at the end of the day, we got the problem solved and we get to do some really cool stuff along the way to figure it out.

my situation, and then the discipline. I think that you know, even after you've agreed on the design, I think there's no substitute for those code reviews, right, Like, that's that's where you're really like, Okay, are we are we really doing what we said we were going to do? We

are we following our guidelines? You know. That's how you make sure that you accomplish that goal and you don't end up kind of in a situation like you describe, where a lot of people find themselves with a code base that has a life of its own, its own personality, for whatever reason that it ended up being created that way. Right, there's always reasons that at the time that get applied, but there's just no substitute for those things. Yeah. I've

worked previously. I worked in environments where we did not review every line of code, and then more recently I did, And it's hard to imagine not having code reviews for everything anymore.

gonna blow this so hard. Practices. There were three levels to it. The third one was ethics practicals. I think it was disciplines. Principles was the principles anyway, go listen to it because he breaks it down. And the first

level was he talks about TDD pairing. You know those kinds of things where you know, like you're talking about the code reviews kind of falls underpairing, right, and then testing of some kind right under TDD, you know, and some of these other things where you're just doing these practices that get you to.

And you know, things like that, and anyway, it was really really interesting conversation and that's the kind of thing that we really need to be talking about too, within our within our teams and with the people that we work with, because at the end of the day, it's not just Hey, here's the technology and the technical approach that we used to solve the problem, but it's yeah, what are we doing to make sure that it's the

right solution to the right problem. What are we doing to make sure that the code meets the standards that we have for the kinds of solutions we deliver, and what kinds of things are we doing day to day in order to make sure that we are delivering for the company that we work for, delivering for the team we work with, delivering for the world at large, and things like that. So anyway, terrific conversation. I'll put both of those links in the show notes, and yeah, let's

go ahead and new picks. I'm going to push it today. First, Dave, do you have some picks for us?

And the whole reason why I picked this up is because I'm building a shed underneath our deck and I'm now getting around to the part where I'm doing the sighting to make it look like the rest of the house. I was not going to be able to do this job without that tool. So it's amazing. And on the date of recording this podcast today is April first, i

launched a new tutorial site. So I've been doing drift and Ruby for many, many years, over two hundred eighty episodes I've recorded on Ruby and Ruby on rails, and so today I've launched a new training site and that is drifting Cobal. So you can go to driftingcobyl dot com and you'll see that it's a completely satire side for April first, but hey, if it picks up one subscriber, that's like ten percent of the entire Cobalt user base, so I'd say that's when.

I put it? It's supposed to be kind of a wiki slash, trellos slash, to do list slash anyway, it does not have any kind of automation, and it doesn't integrate with Zapier, and so I quit using it eventually because I just couldn't.

up a Google doc and do all this stuff. And I'm hoping that I can move all of that into clickup and then just invite our podcast guests as guests

on the test. That's the only part of it. I can't guarantee what'll work because I haven't double checked on that, But for the hosts and everybody else, I can actually go in and do that, and I'm hoping to be able to automate all of that stuff so that then it comes back after the episode and says, because we manually have to follow up, Hey, can we get a description for the episode and a title for the episode? And because I'm not on all the shows, and so I'm kind of the backup on the shows that I

show up for. But if I'm sick or if I'm just not on the show like Adventures in dot Net, I'm practically useless on that show anyway, Right, I can kind of make it up and go look up the terms. I don't know, but realist, right, if they're talking about like some deep library NC SHARP, it's like, okay, what is this thing?

you know, where you're trying to get noticed. I'm putting together basically a coaching program and I currently have five people in there where I'm coaching them every week on Okay, here's how you build an audience. I'm focused on podcasts, So here's how you build an audience. Here's how you build your podcast. Here's how you get people to listen

to it, Here's how you grow it. And then from there it's here's how you build it into Some people want to do speaking, some people want to teach live training, some people want to do courses.

name in. And that's just so that some people, for whatever reason, they hit the thing on their phone, the application, and then for whatever reason they don't get the information in. That's so that I can just remind them, hey, look, yah, filled it out. Can you come back right? And then I'm planning on sending some emails out and some other stuff,

putting some other stuff together there. But yeah, dev influencers dot Com that's where all that stuff's going to be for the podcast, and I'm going to be talking about how to advance your career. A lot of people they get stuck at senior developer, that's the other thing, and they're like, I don't want to be a manager. I don't really want to go architecture or whatever. I want to keep writing code and this is a way you can do that. So anyway, dev influencers dot Com. That's

kind of my thing. And that's not an April Fool's joke. Darren, Do you have some picks for us.

things that I find fascinating about Ruby. But yeah, so engine Yard containers is a great way to quickly deploy those Ruby apps, scale them up, and get some of those observability and other benefits we talked about. Am I allowed to do that for a pick? Is that okay?