Monoliths vs. Services: What Kind of App Should You Build?

Software developers have a lot of opinions and it can be challenging for business owners or even development teams to determine the best course of action. The debate between monolithic and service-based architecture is a common example of these kinds of opinions where there are strongly held beliefs and a potentially high cost of making a mistake.

Let’s take a look at the pros and cons of monoliths and service-based architectures, as well as how to decide on the best option for your business.

What Are Monoliths?

Monoliths encapsulate all of an application’s functionality into a single codebase. For example, Ruby on Rails contains models, views and controllers that all exist within the same codebase to handle everything from querying a database to updating a browser. They work great for newer projects given their simplicity and their consistency can make larger projects easier to manage.

Advantages

• Better Performance. Monoliths tend to have better performance since they live on the same machine and share the same memory.
• Less Complexity. Monoliths are easier to build and test since there’s a single codebase that runs in a single environment.

Disadvantages

• Challenging to Scale. Monoliths can grow unwieldy as the codebase and dependencies grow, making them harder to understand over time.
• Slower Releases. Monoliths tend to have slower release cycles since each update might require changes to the entire system.

What Are Services?

Service-based applications are made up of many small services that communicate with each other. For example, an application might involve several REST APIs that interact with a database and other services along with multiple clients for the web and mobile devices. The approach tends to work best for larger projects that require scalability and different APIs.

Service-Oriented Architecture Example - Source: Neal Ford

Advantages

• Better Scalability. Services can be scaled up or down on an individual basis, which makes it much easier to scale than a monolith.
• Faster Releases. Services are independent from one another, which means different teams can work on them completely separate from each other.

Disadvantages

• Greater Complexity. Services are run by different teams, in different environments, in different languages, using different patterns, making them harder to understand.
• Management Challenges. Services can be difficult to manage from a DevOps standpoint because there may be many different environments to maintain.

What’s the Best Option?

Monoliths have been a mainstay of software development for a long time—and for a good reason. Shopify, Twitter and many other highly trafficked websites ran on a monolith architecture for a long time without any problems. Many monolithic architectures also have well-established ecosystems and talent pools that make them attractive.

Service-based architectures arose out of a need for flexibility. For instance, suppose that you run a bank with a monolith architecture, and suddenly, you need to implement mobile banking—but it requires a different set of APIs. It doesn’t make much sense to add them to the monolith, so a service-based architecture became an appealing option to extend functionality.

The problem is that the pendulum has swung too far in the other direction. Last year, Kelsey Hightower pointed out that developers haven’t been building microservices as much as building distributed monolithic applications. They went from writing bad code to building bad infrastructure that deploys bad code.

Example of AWS-based Serverless Architecture - Source: Amazon

The rise of Kubernetes and serverless technologies have solved some of these infrastructure-related problems for service-based architectures, but in the end, there is no right answer for every application. When deciding between different options, you must evaluate your goals, developer skills and other factors to make the right decision for your business.

Other Key Considerations

The decision between a monolithic or service-based architecture is one of many technical decisions that must be made when developing a web or mobile application. For example, development teams must also decide on a programming language, framework, dependencies and countless other factors that influence long-term success.

Some key considerations when choosing these factors include:

• Application: Web applications, mobile applications and embedded systems all have different programming languages and frameworks. General languages, like Java, Python or even JavaScript may work across different applications, but platform-specific languages may be superior in some cases.
• Complexity: The size and complexity of a project can influence the technology stack. Small projects may be able to use customized frameworks like WordPress whereas larger projects may need to be built from the bottom up. Some applications may even be broken into different “services” that each use their own technology stack.
• Culture: Companies may have their own preferences between open source and proprietary software, dependencies, languages and other factors. If your team is already experienced in one area, it may not make sense to shift to a foreign technology stack since it may involve a steep learning curve.
• Maintainability: Each language and framework comes with its own ecosystem of libraries and some frameworks are easier to maintain than others. Maintainability may also be impacted by the availability of talent in your area. And finally, maintainability plays a crucial role in security.
• Use Case: Different programming languages and frameworks perform differently depending on the use case. For instance, a real-time chat application is better served with web sockets than posting to a database. Healthcare applications may also require a platform that prioritizes security to comply with HIPAA regulations.

In addition to these technical factors, businesses must also carefully plan their development around business requirements. Most Agile development teams focus on delivering working software as quickly as possible by narrowing down the scope. Through a continuous feedback loop, they ensure that customers are informing each new feature and bug fix.

The Bottom Line

The monolith versus service-based architecture debate has been raging for years in the software community. While service-based architecture may be in vogue these days, monoliths have experienced a resurgence in popularity. The right option, however, depends on your business and its requirements as far as performance, scalability and simplicity.

If you’re in the planning stages of a new project, Sharkbyte can help you determine an optimal solution and create a custom development roadmap to guide your future. We can also help augment your existing team with experienced developers to get the project off the ground or take on the entire project as an outsourced development firm. Contact us today!