On today’s episode we are talking about monoliths! That’s right, they’re back. Not quite from the dead but definitely from a deep sleep and the unfavored sock drawer. So why exactly are we seeing a resurgence in the popularity of this form of coding right now? Our experts tackle this question piece by piece and untangle the differences and overlaps between monoliths and their supposed successor, mircoservices. We talk about the ins and outs and when monoliths might be a good idea for a team as well as why starting a project as a monolith makes sense. The team seem to agree that there is no hard rule when working in either of these ways and that the only constant is that no matter which you choose, if you write bad code, the structure is not going fix that for you! So for all of this and more, tune in as we go down the rabbit hole!
Key Points From This Episode:
Transcript for Episode 63. Monoliths
[0:00:01.9] MN: Hello and welcome to The Rabbit Hole, the definitive developer’s podcast in fantabulous Chelsey Manhattan. I’m your host, Michael Nunez. Our co-host today.
[0:00:09.8] DA: Dave Anderson.
[0:00:10.8] MN: Our producer.
[0:00:12.0] WJ: William Jeffries.
[0:00:12.8] MN: Today, we’ll be talking about whether monolith are in for 2018.
[0:00:16.6] DA: Yeah, that’s all the rage these days, Monoliths.
[0:00:21.0] MN: We’re coming full circle ladies and gentlemen, that’s it. We’re back to Monoliths.
[0:00:25.6] WJ: Majestic monoliths coming down the runway.
[0:00:27.8] MN: Yeah, I mean, like, you know, in the past, the Monolith was frowned upon, everyone moved over to microservices and now everyone’s running away from micro services back to monoliths.
[0:00:39.5] WJ: They hype cycle.
[0:00:41.6] MN: Hype train. Back to monoliths. Does someone want to give us a definition or their thoughts on what is a monolith before we dive in to why it’s back in?
[0:00:54.4] DA: That’s a good question, what is a monolith? I guess a monolith, you see them pretty often when you’re starting out a project where you would have like all of the code that could possibly be there in one application and maybe you have a database that talks to it as well so you have one monolithic database, one monolithic application that has all the different kinds of business logic and yeah, maybe a front end too. Most likely just one thing.
[0:01:25.2] MN: Just all your code in your entire company can be jammed into this one code base.
[0:01:32.7] WJ: Yam it in there.
[0:01:34.1] MN: All together, like a monolith. I think of like, the word monolith like Stonehenge like a big pillar of just like all your code, is that safe to say?
[0:01:45.7] WJ: Like a Washington Monument of code.
[0:01:47.4] MN: Yes, that is a monolith.
[0:01:49.0] DA: It’s like 2001: A Space Odyssey.
[0:01:50.8] MN: Exactly. We have the idea of putting your code all together into this one monolith. People started looking at other options and microservices became the thing to do, do we want to describe what is a microservice and how does that help against the conversation of monolith versus microservice?
[0:02:17.1] WJ: Yeah, I think five years ago, they were the new hotness and kind of all the rage everybody was talking about them. I think the idea of a microservices that you break apart your monolith into smaller more manageable pieces.
You decouple things, you separate responsibilities and then you wire those things up to one another as though they were services just like an API like you might hit from some third party. That’s the dream at least.
[0:02:44.6] DA: Right, I think it’s the idea that I’ve read from microservices, it should be anything that you can write and some arbitrary amount of time is like two weeks or four weeks or something which may not always be the case, which maybe one of the reasons why people are kind of moving back to consider monoliths as a valid pattern.
Because your monolith or your microservice may actually secretly be a monolith itself, may have blurred boundaries and separation of concerns, challenges itself.
[0:03:19.5] WJ: Yeah. You start trying to figure out how to share a code between your microservices and now it’s just exactly the same as if you had two classes in the same app except now, they have to communicate with all of the latency of http.
[0:03:35.8] DA: Yeah, also like, the challenges of maybe a communication bus in between them you know, putting everything in a rabbit MQ and getting the response back eventually.
[0:03:46.8] WJ: And having the code live in different repos that are perhaps not version controlled and having upgrades to one repo, break the other.
[0:03:56.2] MN: Yeah, it sounds like a headache you won’t have if you had a monolith.
[0:04:02.1] WJ: Yeah, you’d think you’d have a whole lot of set of headaches.
[0:04:05.0] MN: You have a monolith of headaches, in that regard.
[0:04:08.3] WJ: Which kind of pain do you like?
[0:04:10.4] MN: Exactly, that is the question I ask myself every morning. When building these things.
I think I wanted to mention, when starting out an application, they say it’s best to start as a monolith to not go straight into building microservices as mentioned by Martin Fowler or as I called them earlier, daddy Fowler.
[0:04:33.6] MN: Martin Fowler has mentioned that you must - oftentimes, people who dive into using, to creating just microservices of something often fail and what seems to be the most – what seems to yield the most success is starting out as a monolith and then slowly taking apart what is necessary for it to be a microservice in itself.
[0:04:56.8] DA: Yeah, that sounds like a pretty good application of YAGNI principle where you’re not going to need this service for this or you need to wait until you have the most information aside, what the boundaries between those services might be.
[0:05:11.9] MN: Right.
[0:05:12.8] DA: Always really challenging to do any kid of big upfront design but when you’re trying to do it across multiple services then that’s going to be the more challenging. There’s another article besides the one from Martin Fowler. Big papa Agile.
[0:05:28.0] MN: Yeah.
[0:05:28.3] DA: Called, The Death of Microservice Madness in 2018. Which is pretty dramatic title.
[0:05:34.4] MN: Yeah, that sounds insane.
[0:05:36.7] DA: Yeah, our colleague Adam shared this with us a couple of weeks ago and I found it pretty interesting because I think they break down a lot of the things that we’re talking about here very well.
Talking about kind of like the increased complexity that you need to consider for onboarding a junior developer into this environment and the extra expertise that’s required to orchestrate all these new services and containers and making sure the deployments are properly versioned and all that crazy stuff.
[0:06:10.3] MN: Yeah, it just sounds like, I don’t want to say the learning curve but like the rigidness of maintaining microservices might, like if you’re not maintaining your microservices well and that includes like defining boundaries and ensuring that you have continuous deployment, continuous integration built in all of your systems then it’s like, doomed to fail.
Maybe a monolith makes that a little easier and less of a headache that you can answer later on in life. Maybe.
I’m not 100% sure if that is true or not but I feel like that seems to be like the thing, the difference between the two.
There’s just upfront like militant, best practices must be applied to microservices. If you mess up like a little bit somewhere, it will be very brittle and fall apart.
[0:07:06.2] DA: Right, yeah. I guess if you’re trying to learn how to do something for the first time then it would be challenging to add that extra complexity.
The thing is this article has life, I think is pretty awesome is a flow chart which you can walk through to lead yourself to the correct path maybe for your team and your particular team skillset in your situation with the particular problem domain that you’re looking at.
The basic flow points that they have there are, you should consider how big your team is if you have like two people, maybe you don’t need microservices because like one service per person or something.
How much persistent state do you have in your application? Do you need to like have some knowledge of sessions and things like that. Who are going to consumer your APIs? What kind of dependencies between them and there might be. And also like, do you have the expertise that you need to do this thing?
This seems like a pretty nice, like useful framework to think about that problem.
[0:08:16.1] WJ: The open source community has done a great job of figuring out how to collaborate using lots of smaller projects. You can bring in tens or even hundreds of open source projects of open source libraries and pick a version and lock it and then not really have to worry about it anymore, maybe periodically you go through and do upgrades to make sure that nothing is broken, get any security patches and it gives you a lot of flexibility.
One thing that I have seen companies do successfully when experimenting with microservices is breaking something small out and making it open source. Then pulling it in using the infrastructure that’s already in place for open source.
[0:09:05.5] DA: Just treating it as though it was completely someone else’s thing and no longer a trusted party to you, the core application.
[0:09:15.1] WJ: Then that begs the question, will then aren’t – wouldn’t that make monoliths, micro services because most monoliths are pulling in tens or even hundreds of open source libraries, are they not?
[0:09:28.7] MN: Yeah, but it’s all merged into this one thing that has multiple responsibilities I think, right? The monolith can be responsible at many things versus a micro service that can just – that may be responsible for one thing.
[0:09:45.5] DA: Right, you might have like one container, one server of that fits all of these different kinds of thought and APIs that you’re dealing with, where you’re just like an open sourced analogy to a microservice might be, Constructing your app entirely on free APIs like Google Maps API and Yelp API and what have you like training, glue all of these things together from different sources.
[0:10:13.3] WJ: Yeah, that seems like a better analogy really because open source libraries aren’t services. You don’t have to spin them up, they don’t have to be running in a separate container. You don’t have to hit a separate port over HDP in order to get the functionality.
[0:10:30.6] DA: That’s the slightly less expertise where it’s like, “Okay the barrier to entry to doing this is so much smaller” like you can graduate from a boot camp and then just put everything all in one place.
[0:10:44.7] MN: All right.
[0:10:45.1] DA: Get it onto Roku.
[0:10:46.6] MN: Ship it, ship it.
[0:10:49.3] DA: Yeah, just listen to the ship it squirrel.
[0:10:51.1] MN: Yeah, so I guess some of the things in the conversations that we spoke about part of the reason why monoliths are coming back is because it’s just easy to start up an idea with a monolith and then slowly if necessary putting that into microservices. If you need it because you may realize that that might not be the case.
[0:11:17.1] DA: Right and there are real benefits to spinning up a microservice that you might realize in the situation that you are in. So you could be a real benefit.
Like you might scale your application better because it is more dependent and you might be able to have easier collaboration or more independent collaboration between teams if your organization is scaling.
[0:11:42.8] WJ: Right if you have a comments microservice - if you are maintaining a website that has comments on articles for example, breaking the comments feature out into a separate micro service could provide opportunities for scaling because it might turn out that your ability to serve articles is actually not hampered at all and it doesn’t need any more hardware.
The only area where there is pressure is on comments because they are more dynamic.
[0:12:13.9] DA: Yeah although then like you do need that expertise to look at that problem and be like, “Okay well, if I know that comments are having trouble scaling, I need to make sure that it’s truly following the principles of building a micro service where the comments are hosted in their own place as well,” because if the articles and the comments are both in the same database then you still have a monolith.
[0:12:41.1] WJ: But then what if you want to do a join on comments and articles? They’re in different databases.
[0:12:47.3] DA: Well that’s some challenge I guess.
[0:12:49.9] WJ: Oh man, those micro services are complicated.
[0:12:52.9] DA: Although there are things that people do like to make it easier deal with also you’re having an API gateway like we have talked about Graph QL. Graph QL is pretty popular as an API gateway and there are other alternatives too.
Kind of providing a glue layer to take all of these micro service-y things and do your joins for you and let your application pretend that you secretly have a monolith in the end which I guess also makes you question, “Wait, why did I build all of these tiny things and then another thing to make it look like one big thing?”
[0:13:28.1] WJ: I think there is another good reason for microservices and that is scaling up your tech team. I think that it can become really cumbersome to have dozens and dozens or hundreds and hundreds or thousands and thousands of developers all working in a single code base.
Certainly there are examples of people who have done it. Yes, we’ve all heard about Google and their single gigantic repo.
[0:13:54.3] DA: Yeah, although I think that their single gigantic repo may actually can say many microservices inside of it and they are just trying to avoid the versioning problem with knowing which version of which micro service works with one.
[0:14:08.9] WJ: Yeah but I think you expose yourself to - I think there is an inevitability in software. Conway’s Law which states that software, this through the organization of software will reflect the organization of the teams that built it.
[0:14:23.1] DA: Right.
[0:14:23.5] WJ: So if you have a front end and a back end team then you’re going to have a lot of separation between the front end and the back end in your app.
If you have a customer facing and an internal facing team working on different UIs with different customers and different needs, those are going to - even if they are in the same code base, if they are in the same monolith those are going to start to split and you are going to start to see divides there.
And if you can actually cut it in half, you can find that scene, that breakpoint and split those two teams into separate code bases. It decouples them in a way that allows them to move faster.
You are just acknowledging the reality that is already there and you are facilitating continuous delivery by allowing these people to shift separately.
Although you could argue that those are not really microservices. That is just two regular services.
[0:15:18.0] DA: Right, two different groups beforehand.
[0:15:20.3] WJ: Like duolith.
[0:15:21.1] MN: So duolith, there you go. What’s are three monoliths? Is that a triolith?
[0:15:28.1] WJ: Yes, sounds good to me.
[0:15:29.5] MN: You would have to then think about whether you want to make microservice is not how to think about how to pronounce triolith if that even is the proper way of saying that.
[0:15:39.5] WJ: Triceratops.
[0:15:41.2] DA: That is one of my favorite dinosaurs.
[0:15:43.9] MN: There you go, fun fact.
I think in the conversation we just had there are very, very strict rather the engineering team needs to be very disciplined when building out these microservices so you don’t have faulty microservices and that’s not to say that all monoliths are not faulty either.
Regardless of whether you write crappy microservices with no discipline or a crappy monolith and no discipline, it is just very difficult to work in that code base anyway. So you should always want to use best practices regardless of whether you go down the monolith route or the microservice route.
[0:16:24.5] DA: Right, yeah. If you are hitting on your crappy monolith code or you are frustrated with what’s come before you and you want to build something even better then you want to make sure that you are not going to build tomorrow’s legacy application or instead of having one crappy code base you have 10 crappy code bases in there.
[0:16:45.9] MN: Yeah, you don’t want to do that, for sure.
There is a quote that I saw online from a Hacker News article titled You Must be This Tall to Use Microservices. And I thought the title was great and there is a common in there that says the following:
“Microservices necessitates the application of a more rigorous set of engineering practices to all service infrastructure components and therefore carry a greater overhead than traditional development methodologies. Rigorous engineering does not come free. Whether that tradeoff makes sense for any given project is a question of resources and requirements.”
And I think Dave mentioned before, definitely think about your requirements and things to consider such as team size and state and the consumers who will be consuming information given this application and many other different requirements are very useful to the term and whether you want to go down the route of micro services or a monolith.
[0:17:46.1] DA: Cool, yeah. Good deep thoughts.
[0:17:48.7] MN: There you go, yeah. Are there any teach and learns that we have today?
[0:17:52.5] DA: This is a really small one. It is not like a huge piece of wisdom but I learned that you can actually move multiple tabs in Chrome by using shift selecting or control selecting and then dragging them out of the window.
[0:18:06.8] MN: What? What? Say that again.
[0:18:10.5] DA: Shift select or control select to get multiple tabs and then drag them where you need them.
[0:18:15.9] MN: Wait so that’s like – let’s say I have three tabs that I opened and I want all three of those to be in its own window you shift –
[0:18:23.5] WJ: Well then they already are because you have three of each right?
[0:18:25.5] MN: No, no let’s say I have a monolith of tabs, right?
[0:18:28.2] WJ: You’ve got like 10 tabs right? You click on the middle one and then you hold shift and you click on one that is two tabs away and then those three tabs are going to be highlighted and then you click on those and you drag them away and then they become a new window.
[0:18:41.9] DA: Yeah or if you open up like 15 tabs and they’re all sprinkled around like you have your Jira or your clubhouse or whatever like links and you just got to click them, control, select the ones you want, drag them out. I always do this. I always open up a million different things and then it’s all a mess.
[0:19:00.1] WJ: Yeah.
[0:19:00.6] MN: Oh my god that’s crazy.
[0:19:02.0] WJ: I do that and then I option back take to sort of some error back take to cycle through the different like groups of tabs and then I minimize the groups of tabs that are for after work stuff and then I don’t have to plop them out for the during work stuff and then I will have to try and move the tabs that are sort of cross over from one to another and then it all becomes way more complicated than just opening a new tab.
[0:19:31.4] MN: And you get yourself a monolith of tabs afterwards.
[0:19:34.4] WJ: You just close your tabs. You don’t need all of those tabs.
[0:19:37.2] DA: I need the tabs, I need them. We also take tabs, use quick tabs.
[0:19:41.8] WJ: You’re a tab-aholic Dave, you need an intervention.
[0:19:44.0] DA: Yeah, oh man just Fuzzy Finder for tabs. Quick tabs, for all your too many tabs needs.
[0:19:49.9] MN: I have a quick teach and learn, nothing too crazy. I have been trying to use Facebook recently released the – well not recently but they have like create React tap. It is like a scrip that you can run and you can just create an app on the go and it comes with a couple of scripts including Yarn or NPM start, NPM stop or NPM test.
But the one that I actually tried was NMP eject which means that the application. Or that bundle process that Facebook has that script, bundles up all of your battle and all of your web pack all into this one fine thing that you don’t see until you eject and it is like, “Are you sure? Are you a real developer because you are about to eject out of this and see some stuff.”
So you eject and then like all of the web pack and the battle stuff actually writes into your project and then you can actually make real edits to your battle file and stuff.
Those are scary because those are like, “Oh no what if I go back to…” You know what if you had the, what is it, the red pill and then you want to go with the blue pill and the matrix have to figure out which pills – don’t take many pills.
But you get out of the matrix and then you want to go back in like what do you do? I had no idea, you just have to start a new project if that was the case. So use Git if you plan an eject so if anything you can always go back.
Let’s keep the conversation going on Twitter. Follow us now @radiofreerabbit. Like what you hear? Give us a five star review. It helps developers just like you find their way into The Rabbit Hole and never miss an episode, subscribe now however you listen to your favorite podcast.
On behalf of our producer extraordinaire, William Jeffries and my amazing co-host, Dave Anderson and me, your host, Michael Nunez, thanks for listening to The Rabbit Hole.
Links and Resources:
