Darren Broemmer
Appearances
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
Yeah, I had a similar reaction that Chuck had. If we get into the thousands, I'm completely with you. We've probably gone off the rails at that point.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
I believe that's probably correct. I actually got to work with them a little bit when I was at AWS. They also are a bit of a snowflake because, I mean, there are very few companies or organizations that have the amount of resources that they have. Companies like Netflix, like Amazon, You know, there aren't very many folks that can put that many resources on it.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
And they have 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.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
However, containers are very efficient at this. You can put a lot more container processes on the underlying hardware, and you also get a lot of those other benefits that I mentioned. So I don't know that the infrastructure cost would be quite as bad as you think it is because the container processes are pretty lightweight. They can start up in milliseconds as opposed to...
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
You know, like an EC2 instance probably takes like between 30 and 60 seconds to start up. Whereas a container, let's say, let's round it off to a second. So you can scale those up and down 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 complexity front, I agree.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
There's some point where it becomes unmanageable. Yeah.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
Yeah, unless your databases are of pretty decent size, I would probably go the route you mentioned where if you're talking AWS, you have an RDS database and you can put multiple, not instances, multiple schemas on there, right? So at least you can segregate it that way. You know, if...
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
Many of these microservices, if they have a smaller footprint, there's no real reason to have a different physical instance. You don't need to take that separation to the nth degree. Not to be too salesy, but the company, Engine Yard, also has a ScaleArc product, which is a database proxy, which is also a nice way to... actually get the three-tier architecture independence.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
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 intelligent caching and security controls for you. Again, if you get into larger number of databases, that might be something that's helpful.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
But yeah, packing multiple database schemas on the same RDS cluster is actually pretty good strategy in a lot of cases, unless you have a really high volume or a really large size database.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
Absolutely. So yeah, those two things that we've been talking about, the microservices and the containers, are most certainly independent. So like you were just saying, even with beautiful monolith, containers give you a lot of benefit. They give you this really fast scalability that you just talked about.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
And something we haven't even mentioned yet, it's actually pretty nice for development as well. So developing with containers is
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
really helps cut down on you know 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.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
There's also an open source Gitpod 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 on VS Code.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
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 hopefully you never have to hear the phrase works on my machine again. That helps to alleviate some of those issues.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
Yes, there's a whole other paradigm shift that we now have to think about, right? Well, I know a lot of the Ruby gems do work on it, but there's a handful that don't. And I know the company I work with is actually... We're investing, actually looking for Rubyists to help get all of those gems up to speed on ARM because the price improvement... Sorry, the performance...
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
And price improvement is really significant. So it's a big boost.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
No doubt. 100% agree. Now that I'm a developer evangelist, I shifted from engineer to, I guess you could say I'm on the marketing side. So still an engineer at heart. But the phrase game changer gets overused so many times. When you go to conferences, you hear, this is a game changer. That's a game changer.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
I think the use of ARM, what we're talking about here, I think actually does fall into that category. 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's a really nice way to solve that problem.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
Certainly cost effective there. It's a lot cheaper than the person hours that you might spend diving into that potentially.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
Yeah, it's a great question. So, you know, I mentioned that earlier, I wrote a book with the phrase best practices and a title. And I think I have a little bit different opinion take on that now. I believe that the use of microservices, what we've been talking about, is a great practice to do if it works for you. And it's probably, you know, it's not a one size fits all.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
So it's more of a concept that you can apply to your situation. If it's really hard to to untangle those concerns, maybe you just keep it in that single app. Maybe it's not worth doing, not worth the effort to break it out.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
Yeah, that's a great example. And I think that if you've identified that as a need, it's used in more than three places, which is a good general rule for reuse. So you want to package that up and not repeat yourself across that group. So how do you deliver that capability to the other users of it or even reuse it yourself? And so...
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
You could just point the other teams or the other developers 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 microservice, and it is. It's well-defined, and it is. That's a perfect use case for a microservice. I will say, Chuck, you also brought up the authorization.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
So those kind of non-functional concerns are... prime candidates as well. They're easy to separate out from the rest of your application. That's where you get into the nitty gritty of the business logic or workflow where it becomes a little bit harder to do it.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
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 was 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.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
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 or not always going in the same direction. But
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
All of these different web services are not, it's not really, customers think about it as one infrastructure or platform that they're using, but it's really 150 different services. I think the number is actually higher probably now. And so when you're building one of those, you're using easily 10 or 12 other ones in order to compose your application. I worked on a security service.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
I helped build Resource Access Manager. In terms of monitoring and other things, obviously, we didn't build our own monitoring service. We use CloudWatch, for example. Authorization, of course, we used IAM, Identity Access Manager. So it's really... Those are good examples of large sets of services. You can think of them as microservices. Some are more coarse-grained.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
But in order to build up these really large, really large platforms that can do amazing things that run a majority of the internet when you think about it. And so there's a lot of capability there. Again, it comes with the caveat like we talked about before. Those type of companies have... armies of engineers who can work on all of these things.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
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 you're working on. But yeah, there is no one right answer. You always want to apply it to your situation.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
Yeah, I would... So here's where we get into... I would evaluate the deployment or sorry, the operational aspect of it and see what you can get there. So if it's a sidekick job, you're going to have a little less, you'll have to make sure you build in the metrics and the visibility to see how that is behaving.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
If it's its own microservice, which you can, let's say it's in a container, I can observe that independently very easily. I can scale it separate from everything else. 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. Right.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
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 that 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?
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
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 it is.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
Yeah, so I think when you're looking at decomposing your application and doing design, you know, and really there's only one reason that we really do software design, right? We do it because we're probably going to need to change our application tomorrow, whether that be to fix some bugs or to add some new features that people want.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
So having it 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 maybe it's nice to have it in a separate deployable unit.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
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 add capabilities?
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
We can't, you know, add patterns and layers of indirection everywhere. So we need to make choices. I say that because every time you add a layer of indirection, it's not free. 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.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
That's a great analogy for separation of concerns. I got to remember that one and use that in the future. The dogs in the fenced-in backyard, I like that. Yep. Yeah, I mean, I think that You brought up a really good point. It's like, well, you know, we're all if we're all in the same backyard, you know, how long will it be until we all, you know, cause problems?
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
We bump into each other trying to get our work done. You know, one person is cutting the grass in the backyard while the others are trying to play volleyball. It just doesn't work very well.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
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 be in, you know, app and lib. It's actually as you get bigger and bigger where it becomes easier. more of a challenge because changing one thing has ramifications in unintended places.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
And that's really one of the big challenges. There's a pretty nice tool that I've been working with or testing out called App Land. And 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 like to have a visual or mental model in my head of,
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
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 I first started doing Rails and Ruby, which I mentioned like six, seven years ago. And when you do Ruby or sorry, when you, excuse me, when you do Rails new,
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
It's interesting. You actually get, I think it's about 50 files with 500 lines of code, give or take. And Rails isn't embarrassed about this either because you can do bin Rails 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?
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
If I was going to compare that to Node.js, for example, I think probably one file, maybe what, like five lines, something like that. But there's also the positive aspect of it that it prescribes a lot of things for me. 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.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
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.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
I will say the one having worked on a lot of different projects and 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 class is pretty rich and has most of what you need. So we don't have to deal with that.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
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 spent into that. Now, how many of those projects ever actually swapped out databases?
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
But, you know, helper directory is always things like that can get messy pretty quickly if you're not careful. My daughter has a Maltese 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 would stand by my side.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
He'd be down the road checking things out that he's probably like, finally, I get to go run around.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
So... Engineers will always find a way. Now we're into Jurassic Park.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
Yeah, that's really well said. These are different tools in the toolbox. And yeah, solving problems is one of the greatest parts about being an engineer and doing what we do. Probably closely followed by seeing our users and customers actually get to take advantage of these creations that we put out into the world. Yep, absolutely.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
I can think of maybe one that went from a relational database to a NoSQL, and they had to make broader changes anyway. So 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 cake, down as far as you can.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
Yeah, those two points were spot on, right? At the end of the day, there's no... Until AI advances to another level, maybe, there's no replacement for the design and the discipline, right? So you do that design upfront and it's like, what's best for my situation? And then the discipline. I think that even after you've agreed on the design, I think there's no substitute for...
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
those code reviews, right? Like that's where you're really like, okay, are we really doing what we said we were going to do? 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 described where a lot of people find themselves with a code base that
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
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.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
validations you'll always need to do before you persist to the database. Yeah, put it in the model class. But it becomes very tough when you think about this. There's lots of best practices 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, the equivalent of a Rails action, a controller method.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
And it's hard to imagine not having code reviews for everything anymore.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
Wow. That's amazing. I actually did Cobalt when I first started programming, dating myself again. So this is great to see.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
So if I'm a... You want your code to mirror the real world as closely as possible. And I was... You mentioned earlier, I've probably given bad advice in my career in the past too. I used to be a 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...
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
Yeah, your data formats and... Oh, I'm tweeting it right now. It is a good call out that we are recording this on April 1st. When you all asked me to be a guest on the podcast, I wasn't sure if you were joking or serious. Hey, you scheduled it, not us.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
of objects and entities. So let's say I'm gonna 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 gonna go pay my bill. It's an action I take, something I do.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
Yeah, Darren Bramer, yep. Bramer, ah. And O-E, it's a German, German A sound. Ah, nice.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
Yeah, well, I'm going to go ahead and mention if you like Ruby and Rails and you like getting those benefits of containers that I talked about, definitely check out Engine Yard Containers. That's the next generation platform. You can go to engineyard.com. You can also on that site go under resources on the blog.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
You can check out my Ruby unbundled blog where we talk about the different architecture concepts and other cool 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 pic? Is that okay? Absolutely.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
So that does help. I'm ahead of the game. Yep. I would throw in, I mentioned the other app land is a really nice way to figure out what's going on with your code base as well. I would throw that out there as my other pick. They have, I think app map is actually the gem. App land is a site if you want to share those across different users on your project.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
I am at Darren Bramer, D-A-R-R-E-N-B-R-O-E-M-M-E-R. I probably need to get a better Twitter handle, don't I? That's too complicated, but it is my name. So you can find me there. And on GitHub, I have my old user ID, just letter D and then the first seven letters of my last name, D Brome. So that's me on GitHub.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
And so you can try to push logic further down the 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 bill. Now, I personally wouldn't do this, but let's say I was late. I'm paying my bill, so I'm going to incur a fee.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
So that's probably another service to calculate what the late fee is based on when I submitted all of that. So 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 year. every so often.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
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 that closer, you're going to be better off in the long run when you need to make changes. So now segue that into microservice, because microservice often has the connotation of being a separate physical deployment.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
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 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 referenced was really just, well, how do I take that first step?
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
How do I go from the beautiful monolith to whatever my target architecture is, whatever your favorite 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 your middleware, that controller action is actually a Rack, its own Rack application.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
So in the Rackup 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?
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
absolutely yeah well first of all thanks a lot for having me on here it's great to talk with you guys so i've been engineer engineer my whole life i will admit that i discovered ruby a little bit later in my career i was a java guy for quite a while and going all the way back to 2002 i'm going to date myself here i wrote a book on java j2ee actually so there you go that there's a dated uh bit of technology a little bit
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
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 code base, 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...
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
you know how they behave if one if the cpu goes off the rails on one of them it's going to be easier to identify where the problem was so you don't you don't get those kind of advantages until you actually make them true microservices 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
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
kind of an overview of where i'm at there 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 microservices to break that out from a logical design perspective and then the the actual deployment get the observability scalability independence i think there's a lot a lot of benefit there
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
Yeah, that's a great question. And you're poking at why you want to obviously think through these things carefully. But yeah, no, it's a great question. So what does your data architecture look like? If you're starting out with the beautiful monolith, you do likely have that single transactional database.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
So to the extent that you can segregate out by which objects, which models or tables are being used by sets of services, You're better off segregating those and making those their own deployable units. You're still going to have some potential level of contention because you've got different apps talking to the same database. And so one could certainly impact the other.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
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 where I need data from both places.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
And you can end up getting into performance issues because you get... pretty chatty between these services. So 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 good isolation boundaries to use? And again, it's not a black and white topic, but there's no crystal clear answer there.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
But I think there's 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 faster.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
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 lose customers we could have. So there's so much pressure to get features out there faster. And so, again, you can't optimize for everything, but it's thinking about, well, what is going to benefit me now?
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
And 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 combine the two things I really, really enjoy. So the technology, obviously, but also communications.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
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.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
But if it's all in the same kit and caboodle 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 ongoing impact to your customers.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
And so that is something that I think really hurts teams, their velocity, when you've got to make sure that these 12 or 20 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, microservices really... help you there.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
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.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
Yeah. So there's a number of solutions here. I think one nice way to start is just to And here's where an abstraction does actually benefit you because you can put a facade in front of your service. And so maybe you start out with just actually just calling inline. You're just calling the class directly in your same Ruby process.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
But then that positions you so that when you do move it out to a service, you can swap that out and it's less of a problem. In terms of the domains, I personally like having the different subdomains Part of that, I guess, the product that I work with, EngineR, facilitates this pretty nicely where each of your apps within the same application just get different subdomains.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
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 if you get it into containers and you can segregate, then you get those benefits of the physical deployment also. So to me, I prefer to try to keep it simple.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
Certainly, there's a couple different choices there. I mean, I would probably, if you can avoid... Putting messaging layers in between. If you can keep it simple, rest calls, unless you need to do something different, I probably would advocate for that. Keep it as simple as possible, but no simpler. But there's also other tools and frameworks that help you do that.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
I haven't worked with it in detail. AWS has Service Mesh, which helps you orchestrate all of these microservices. So there are things out there that will help you manage all of this. And probably those are worth it if you really get into large numbers.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
If your enterprise is truly bought in and you're going across many different departments and many different organizations, that's probably when you look at something like that.
Ruby Rogues
Architectures and Microservices with Darren Broemmer - RUBY 657
And so now I kind of went and switched gears. I'm now the developer evangelist for... Engine Yard and we have platform as a 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.