Choosing Between Monoliths and Microservices

4-minute read

Remember the Rolodex? What about the brick phone? Remember how advanced the Palm Pilot felt? Here we are, years later, with vast information right at our fingertips on hyper-connected mobile devices that do much more than make calls and store contacts—they run apps of all shapes and sizes. The process of creating, storing, and accessing information has changed significantly with each new technological leap, bringing with it both incredible benefits and head-scratching challenges.

The same is true for software development.

When software was first being widely developed in the 1990’s, monolithic architecture was king. Nowadays, microservices are sweeping across many industries as the new favorite. So which is best? Let’s have a look.

What is monolithic architecture?

In monolithic architecture, applications are architected as single units: required services are written into one document of code and supported by shared resources, power, and memory. Clients are connected to a single user interface, which then connects to a single server-side application and single database.

Pros of monolithic architecture

• Fast initial setup. Since code is written as one single unit, the process of creating a functional architecture is faster than it would be when trying to separate these into encapsulated units.

Cons of monolithic architecture

• Dependence. Monoliths are highly coupled; services are interdependent and difficult to separate when creating, maintaining, or troubleshooting.

• Agility. Because software is highly coupled, it has difficulty responding to adjustments required during development. Changing one element almost certainly affects other parts of the application due to rampant dependencies, and the entire adjustment can quickly fall apart. Also, the first instance of software being fully up and running is at the end of development.

• Cost. It’s hard to estimate data requirements up front, so determining required resources is usually a guessing game. Potential assets can sometimes sit idle due to changed plans, sinking business funds into unnecessary materials. Monoliths are also harder to test, since software is only deployed as a single unit.

• Version control. With all DevOps members and engineers sharing access to the same service, maintaining clarity can be difficult. This results in complicated branching; having too many options for how to proceed (with too many people involved) can lead to decreased productivity.

What are microservices?

Instead of creating software as one unit, microservices allow developers to use smaller, self-contained units and encapsulate them, keeping processes discrete. This strategy minimizes any unintended consequences whenever code is changed. Though the up-front cost for this encapsulation might deter some, the benefits of operating with microservices quickly justify the spend.

Pros of microservices architecture

• Independence. Elements in microservices architecture have low coupling and high cohesion. Each component is encapsulated based on function using SOLID and GRASP design principles:

a. Low coupling allows components not to depend on (or get tangled up with) others.

b. High cohesion simplifies maintenance and allows for future use via duplication.

• Scalability. Duplication of services is easy with microservices, allowing for rapid iteration of new systems.

• Productivity. Virtualized, scriptable resources allow for more reliable continuous integration and continuous deployment.

• Speed. Microservices allow for deployment at the container level instead of OS level.

Cons of microservices architecture

• Up-front cost. In comparison to monoliths, microservices do have higher up-front costs. For companies that began before the invention of microservices, monolithic architecture has been the standard structure, and change management is required to successfully transfer to a microservices-based architecture.

• Accessibility. Because developers each handle their own service, integrating changes between microservices can sometimes be slowed because of poor communication.

Choosing between monolithic and microservices architectures

When deciding between monoliths and microservices, it’s important to consider a few things:

• Team size. If your project or company does not require diverse and plentiful solutions, monoliths may work well for you. On the other hand, microservices give more control to each team member and prepare your business to scale appropriately as you grow.

• Change management. For most businesses, change happens every day in a multitude of ways: mergers, segmentation, revised business logic, etc. Software improvements are never finished because businesses never stop changing. Microservices are a good option for those who need to prioritize flexibility.

While there’s still no way to predict the future, industry trends continue to favor microservices as the best architecture strategy in 2019. If you’d like to know more about how to move from monolithic architecture to microservices, connect with our technology consulting team using the form below.