Monolithic vs. Microservices with Flagrant’s Jim Remsik

This is Textron tv. Hey guys, thanks for throwing. We're here with Jim Remsik, who is CEO for a company called Flagrant.

And we're talking about, well, the revenge of the monolith. It turns out that after all these microservices have been built, maybe they're a little bit tougher to deal with than we initially thought, and people are trying to find out, well, how do I strike perhaps some balance or maybe even just shift back. Jim, welcome to show.

Thanks so much. I think as we look at this, to be fair, software architecture's coming in and out of fashion. Some things have been around for a while.

I mean, we're all talking about event driven architecture. I seem you remember having this conversation 30 years ago, and it's back again. What is your sense of what's going on here?

Because clearly, um, microservices are difficult. They were in vogue, but are they still in vogue coming out of Vogue? What's going on?

Yeah, I think, uh, microservices are definitely, uh, had their moment and they are still a tool that is very valuable. Um, the thing that I would say is that they are, uh, they bring with them a lot of, uh, unexpected costs, especially the fact that they have been the default paradigm, I think is the, the thing that I would push back against a little bit. Um, because they're necessary, uh, if you're operating on Netflix or a, uh, Shopify scale, but there are a lot of people that, uh, never get, never sustain their business long enough or, or the projects never live long enough to get to those, uh, problems.

And I think that a premature optimization, uh, for a future that never arrives is the reason that they don't get there. I think a lot of the argument for microservices was driven by two things. One is they're easier to update, so you could add more functionality as you went along.

If you needed to do something related to security, you could isolate the issue, especially if you're using containers, you can rip and replace. So what went wrong? Well, I think, uh, it is easier to pull out one instance of a server and, uh, make security updates on that.

Uh, but the orchestration having to go through and make sure that everything is, uh, humming along at the same versions and, uh, all running the same interfaces and whatnot, I is the, the reason that I think a lot, uh, a lot of complexity creeps in the, uh, you know, with a monolith pattern. Uh, you know, it is all sort of self-contained and you don't need to orchestrate deployments, uh, and, and development, uh, at scale like that. I think we're both old enough to remember, uh, service oriented architectures.

I feel like we had this conversation two decades ago speaking to things coming in and outta fashion. We didn't seem to learn our lessons from that timeframe. So, um, why do we keep doing these things and why do we kind of shift out of time?

Is it just because a, a a newer era of developers show up who don't remember what happened 30 years ago? Uh, you know, I think that's absolutely correct. Uh, one of the reasons that I'm pushing for this as well as some, you know, some of the other technologies that I, uh, I push for, uh, with my clients is that, you know, the, these grays were earned.

And, uh, you know, I've seen a lot of things, uh, come in and out of fashion and, um, there's, you know, there are folks that have been around, had whole careers now, uh, that weren't around for that, that earlier phase. And so introducing them to concept like it doesn't always have to be this complicated. Uh, there was a simpler time and, and maybe that's okay.

I I would push back that, uh, the, the monolith can, uh, scale further than most people, uh, are, have been led to believe. There are some people even say, if you can avoid microservices, you should, because they are difficult to manage and they only lend themselves to certain use cases. I, I think that's absolutely correct.

The, uh, uh, again, if you're working at a, uh, either a scope or scale, the likes of Netflix or Shopify, undoubtedly you're gonna have to go into a, uh, an orchestration, uh, and complexity of that, uh, scale. I, I think monoliths are easier to develop, easier to deploy, easier to maintain, and there's, there's less investment required upfront. Some people say, if I put an API in front of the monolith, it's just a big microservice.

So is that a feasible way of thinking about things? And there's just gonna be small things and large things, and they're all connected through APIs, and we shouldn't be hung up about what was used to build what I, I think that is a, a good train of thought. And, you know, you can build a monolith and wait until you wind up getting to a position where there are, uh, either issues of flexibility or scale, uh, and address them.

And one of the ways that you could do that is with microservices, I think not buying into this is the, the paradigm that we have to follow, because that's what everybody does these days, is, uh, where I would encourage people to, to look like, let's feel some pain. Let's, uh, grow the, the monolith and, uh, get to a point where it doesn't do what we need to do before we, uh, assume that we're gonna get there eventually. Why you tell the security people, 'cause they kinda like microservices in the sense that if there's a vulnerability that's easier to rip and replace, and they can't get developers to go back in and patch these monoliths because, well, the developers have moved on and there's always been this something of a disconnect.

And is there a way to bridge that divide in the, and still have monoliths? I think that, uh, the, I, I think the same, uh, complexity and the same concerns exist with microservices. Uh, I've worked in shops where, uh, with clients where a single developer spun up a service in a language that nobody else on the team knew and then moved on.

And so they didn't have the ability, they didn't have internal knowledge to upgrade it and to make that secure. And so I, I don't think one, uh, you know, microservices versus monolith makes you more secure. I think that, uh, with a microservice, uh, uh, topology, like there are, there's a much wider surface area for security attacks and having to keep all of the, your, uh, instances, uh, up to date in a, uh, with security patches and what have you, means that, you know, there are, um, there are downsides to that approach as well.

There's a lot of gnashing of teeth these days on the subject of developer productivity, of course, as far as I remember, this was always an issue, but it seems to be something we're a little more focused on with the conversations around DevOps and platform engineering and all this stuff in the backend. From your perspective, what is the real challenge for developers in terms of their productivity? I think, uh, developers, uh, and speaking from experience, I'm a developer, like, uh, developers are gonna take the time that they're allotted, uh, to do a thing.

And so that means if, uh, they're going to make things more complex, they're going to try new technologies. Um, and, and that's okay. I think what I would encourage people to do is to, uh, focus on, uh, simplifying the environment to the point of, you know, having agreed upon, you know, either framework, language, what have you, um, we've gotten to a, a place with a number of, uh, our customers where they had developers more or less going rogue because we could deploy a microservice in any language.

And so people did. And, uh, I think that meant that if it took a little bit longer to do it in that language, was it because they were learning that language or was it because that language was a little bit slower? Um, and so it, it becomes harder to manage.

Uh, you can't compare apples to oranges when it comes to productivity. And, uh, I think all those things lead up to, um, you know, encouraging a shared culture of, uh, practice and, and technology and technique. How much of this is art versus science?

And I ask the question because just because I am make more time available for a developer to focus on coding doesn't mean they're gonna actually write more code, because, well, there's this thing called inspiration that has to strike. So how do I kinda understand that in a way that doesn't try to impose some sort of factory model on developers? Yeah, I think that, uh, there, in my, in my experience, there are fewer things that are more inspiring than a deadline.

Uh, but you also at the same time don't want to, uh, you know, have unrealistic expectations of your developers. And so there is a little bit of art. Absolutely.

I think that, uh, we have designers on the team, and I think a lot of people look at design more is an art than, than development. Um, and that's, that's true. But, uh, both of them are creative and I think that, um, you know, there, there you have to put constraints around people in order, uh, to make sure that there are expectations that everybody are aligned to.

We, of course, have been trying to bridge this divide between developers and IT operations teams for as long as I can remember. We all embrace best DevOps practices to achieve that goal, but we still have incidents where, you know, it works on my machine, but it doesn't work when it gets deployed. So deployed fundamentally, what's the issue here from your perspective and what can be done about it?

I think, uh, anything that we can do to automate, uh, environment setups, uh, such that, uh, our development environments are as close to the deployed environments that they're going to, uh, be living in eventually, uh, is ideal. I think that it is, uh, that's a not a small task and, uh, not someplace that I would start on a smaller project, but the, uh, there's the environment and then there's the integration. And I think that it, it comes with a territory when you've got more than one person working on a project that there's going to be conflict and there's going to be, um, uh, points of integration where, where things just don't work like they did on one machine.

Uh, I, I don't think that you'll get away from it. I think the best that you can do is try to manage, uh, when it arises how to resolve it quickly. All right.

Well, we've been chatting for roughly 10 minutes or so and we haven't mentioned ai, so here we are. Um, what's your sense of what the impact AI is gonna be on developers and the implications for how code is written? Some folks are like, well, it's helpful for developers who aren't really good code writers, so maybe it makes them better writers.

And other folks are saying, you know, by the time that I vet everything that that machine creates, I had it written it myself, so I don't know, somewhere in between the two, where are we? Yeah, there's a lot of enthusiasm for AI these days and, you know, on my team as well. Um, I think what it has, uh, been especially, uh, productive for us is to take reference material and, uh, you know, things that you and I would've spent time digging through books to find and giving us a, a nice interface to, to get at established knowledge.

Um, the, I think what the, the bigger issue that I have is when you allow, uh, AI to write code for you, and especially if you write code that you're not exactly a hundred percent sure what it's done, um, and, and how it operates, I think that is, there was a recent survey that said that, um, ai, uh, I think it was copilot, um, assisted code led to more churn in code bases. Um, and I, I think that at the end of the day, it's, it's very similar to, um, you know, us reading books back in the day, we can copy the code and, uh, you know, we may or may not understand it. Um, but it is the speed and intent with which the code is, uh, shared, I think is the, the biggest thing.

We are still in the honeymoon phase with ai. I think that there's still an opportunity for, uh, malicious intent and, uh, whatnot to creep in. And I think that, um, it does have the ability to turn your, uh, your one x developer into a two x developer.

I don't think it's gonna 10 x your developer and, uh, but it, it comes at a cost. And so I think leadership should make sure that they understand, you know, how those tools are being used in their, uh, in the environment in which they're operating. So are we in danger of a scenario where we're creating so much code so much faster that it will overwhelm our ability to manage the code bases and get all this stuff into production environments?

I mean, do I need AI to help on the back end to deal with all the AI on the front end? I, I, I hope not. I think the, uh, the thing that I would, uh, encourage people to do is, um, you know, you still have to, uh, you still have to define the systems that you want created.

Um, and so I think that there is a, um, there is, you know, a discovery phase, there is a requirements phase. Uh, the code that gets written to satisfy all those still has to do with the things that it has to do. Um, and so I don't think that we'll ever get into a scenario where there is, you know, AI written code that is being tested by AI generated systems that is being consumed by ai, uh, uh, consumers.

And so eventually you're going to wind up with people and the the people will be the ultimate test. So what's your best advice to folks that are trying to interact? Some of them might wanna manage developers, but they're not developers themselves.

What's that thing you can tell them that this is how you kinda get developers to rally around whatever cause it is that you want 'em to go execute? Yeah, I mean, it's, it's funny, it's not technology at all, right? It, it's people, you have to, uh, help them understand the business goals and the results of, uh, meeting, meeting those goals.

Um, they, and put it in terms that they understand and can appreciate. Um, you know, I I don't say this lightly. We, we take a lot of time.

We, we develop our team, uh, very specifically, but if you, if there are people on your team that are, are not rowing in the same direction, then, you know, you've gotta make a change there. I, I think the, the important thing though is to make sure that, uh, everybody is aligned and, uh, and understands the expectations that are laid out, not only of them, but of you and what success looks like for everybody. All right folks.

You heard it here. Technology is awesome. It's cool, but at the end of the day, it's all about the people.

Hey Jim, thanks for being on the show. Thanks Much for having me. All right.

And back to you guys in the studio.