Monolithic Apps vs. Cloud Native Apps?
It’s a no-brainer that Cloud Native apps are what’s hot right now. But for those of you who are unfamiliar with these terms, I’ve got you.
Monolithic is the traditional model of architecting apps. You can think of a monolithic app as a single codebase where all different functionalities exist. For example, say Facebook followed this traditional monolithic style. That would mean messaging, marketplace, photos and pretty much all of the other services that serves it’s own unique responsibility, would all be meshed together as a single unit of application. Can you imagine how insanely huge that codebase must be 🤯?
Cloud Native apps are pretty much the opposite of Monolithic apps in that it modularizes each of those services. A fancier term for these autonomous services is microservices. Instead of having all different functionalities of your app be stuck to one another in one huge repo, you can have multiple small repos (each repo closely representing a core business functionality of your organization) which contain loosely coupled microservices that work together to help you deliver value to your customers faster.
Before I dive into explaining how, I just want to say that faster deployment cycles is only one of the many reasons why top-notch companies like Netflix and Amazon have adopted the Cloud Native way of building applications. To better understand why, I’ve whipped up a quick summary of my favorite reasons to adopt the Cloud Native way of architecting apps.
Why Build Apps the Cloud Native Way?
Smaller = More (Productive)
Ever heard of the term, “Less is more?” Well, when it comes to building apps smaller can actually result in bigger productivity. When using microservices to build an app, everything is generally smaller; smaller teams that take full ownership of smaller codebases that use smaller services. And if you didn’t already know, smaller teams tend to perform better than bigger ones. The reasons are self-explanatory; it’s easier for leaders to manage and engage with their team, there’s more communication and trust between teams because collaboration is now a requirement to achieve the company’s goals/vision, and everyone in each of the teams feel a sense of ownership and responsibility for the service they’re working with and thus works towards quality code for a better deployment experience.
Quicker & Safer Delivery
Speaking of deployment, since the services are loosely coupled (isolated components that work with each other) making changes to the codebase means tweaking a single service and deploying it independently of the rest of the app. If we were dealing with a Monolithic app, making a tiny change would still require for the entire app to be deployed; which means playing the waiting game and praying that nothing breaks. And if anything did break, since our Monolithic app is made up of intertwined-spaghetti-type of services, then our entire app is doomed to stop working.
But we’re smart and modern web developers. We built this app the Cloud Native way 😎. Which means problems that occur at deployment stage can easily be tracked down to it’s own host/service and be rolled right back.
New Features, New Tech, Whenever
You know what else becomes easier when each of your team is working on smaller codebases? It’s easier to implement new features or integrate new technologies! Adding a new feature will only impact the services you’re working on. This is ideal, since we all know that bugs from this change are way harder to resolve when you’re dealing with a million lines of code. And if ever you want to experiment with Go, Elm, or any of the groovy new languages on the rise, you can; you’ve got a variety of options/services to dabble with these tech in (though you might want to choose the best tech for that specific service/functionality 😅). If you want to use Angular for the front end, and Go for backend of your messaging service, it won’t hurt any other service so go crazy!
It’s Not a Fairytale Ending Tho
Honestly, there are so many other great reasons as to why people are building Cloud Native apps, but I’m going to end the Fairytale story here and give y’all a gentle slap back to reality. Though Microservices are awesome and all, they do come with some baggage of work. One of them is strategically designing your system with strong knowledge of how distributed systems might fail. A quick aside, the way your isolated services communicate with each other is through network calls. And as we all know, networks are prone to failing. So this, along with other ways distributed systems can fail which you can google yourself, is something crucial to keep in mind before starting your Cloud Native app journey.
That’s it for today,
Now that you have a few of the information you need to compare Monolithic and Cloud Native apps, it might be fun to consider these two options when it comes to designing your next project. I mean, I know Cloud Native apps offers you the most positive features but is all of the hard work of designing a resilient-to-new-sources-of-distributed-systems-failure architecture worth it? You tell me.
As always, I encourage you to answer the core question I tried to tackle in this article (Monolithic vs. Cloud Native apps). If there’s any confusion, drop a question in the comments section below; I’d love to help.
Alright, see y’all tomorrow! But if you want to stay in touch until then, catch me on 💁Twitter, Youtube or Instagram.
