Monolithic vs Microservice: Can Davids Really Take Down Goliath?

Robert Stone presented a comparison between two different styles of architecture: the monolith and microservices. This presentation was focused on convincing a company of the benefits of changing architectures.

Monolith

He began by describing what he means by the monolithic style. In a monolith, all of the components of the system work closely together. These components are written in the same language, using the same frameworks. They are pretty tightly coupled. The monolith must handle the entire operation of whatever task we are trying to perform. It must also act independently of other applications in the company.

Monoliths are not all bad. Robert described a number of advantages:

• Faster early development
  • Single codebase
  • You only need to implement any boilplate once
• Easier to test
  • Especially end-to-end integration tests
• Low communication cost
  • All components are internal

On the other hand, monoliths have some definite disadvantages.

• Deployment is high-risk
  • Any deploy risks everything
  • The impact of changes is hard to localize
  • Harder to leverage CI/CD
• More expensive to maintain
  • Larger codebase
  • Potentially higher Bus Factor
  • Steep learning curve
  • Longer onboarding
• Difficult to scale
  • Competition for resources
  • Horizontal scaling requires full duplication

Microservices

Then, Robert went on to describe a Microservice architecture.

• Containers
  • Separate out infrastructure concerns with multiple applications
  • Docker
• Well-defined interfaces for communication between parts
• Services handle the actual functionality
• Persisent Data Store
  • Database
  • Filesystem
• Third Party Integrations
  • Abstract and encapsulate standard functionality

He did not shy away from listing some of the disadvantages of microservices.

• Higher initial development cost
  • Testing requires mocking to test only one service at a time
  • More moving parts
• More complex infrastructure
  • Multiple containers required
  • Additional administration and monitoring
• Higher level of architecture required
  • More thought/time needs to be applied to separating functionality
• Communication between services
  • Latency, etc.
• Strictly enforced interfaces

On the flip side, he described a number of advantages as well.

• Low-risk deployments
  • Isolated functionality
  • Fault tolerance
  • Frequent, small releases
    • Leading to more feaures, faster
• Easier to maintain
  • Isolated/decoupled services
  • Better organized and easier to understand
  • Each service can use the best technologies
    • and can change separately from other services
• Efficient to scale
  • Horizontal scaling of only needed services
  • Isolated resources
• Code reusability
  • Authentication is authentication
  • Decomposition of functionality
• Speed of development
  • Easier to parallelize

Migration Strategy

Obviously, changing from one approach to another cannot be accomplished instantaneously. There must be a migration strategy.

Robert recommended a feature-driven approach. Convert one piece at a time. The order of conversion should bde driven by business priorities.

To mitigate the risks of a change-over, you should not just flip the switch, turning off the old solution and turn on the new one. A safer approach is to run the new functionality in parallel with the existing functionality. That allows you to compare the two on production data and resolve any inconsistencies. You can then retire the old functionality when the business is satisfied. Done correctly, this allows for a ramp up period. Aim for some early (and fast) wins. You can deliver value while ramping up.

Final Considerations

When comparing the two archiitectural approaches there are a number of dimensions to consider.

• Time
  • How long to develop an MVP?
  • How long to add new features?
  • How long to deploy new releases?
• Risk Tolerance
  • What is the cost of an outage?
• Team Size
  • Do you have enough members to parallel development?
  • What are the specific skills and talents on your team?

Audience Discussion

After the talk, the audience had some commentary. They suggested that containers are not a requirement for the microservices approach. Removing that requirement might make converting somewhat easier. It was also suggested that the advantages of microservices that we presented are possible, but not guaranteed. It still requires work. These advantages are not automatic.

The overall consensus seemed to be that the presentation was really good, but could use a little tweaking.

We had 9 people attending this month. As always, we'd like to thank HostGator, LLC for providing the meeting space and food for the group.