Should your startup use microservices?
With industry leaders like Monzo [1] and Netflix [6, 7] preaching how crucial microservices have been to their success, many companies and startups are having the conversation on whether microservices should be the go-to architecture for them. In this article, we will explore the factors which influence whether a new project should adopt microservices, and break down some of the pitfalls of blindly adopting a microservice architecture.
Do you have enough resources?
Before jumping onto the microservices bandwagon, start-ups should consider if they have enough resources to tackle the associated complexities. Richard Clayton [5] equates adopting a microservices architecture to paying an upfront cost, in exchange for avoiding the future problems of monolithic applications. He recalls how he failed in Berico technologies, due to a lack of engineers skilled with microservices. For one, they had to experiment with a lot of different communication patterns between services, eventually running out of time against an aggressive deadline.
Even with experienced developers, the complexities remain non-trivial. Lyft [10] talks about how services were getting increasingly difficult to troubleshoot since a problem is likely to involve multiple services and hence multiple independent teams. In response, they had to build Envoy, a complex service mesh. Similarly, Facebook had to build Canopy, a distributed tracing tool, in order to monitor its thousands of services.
Evidently, microservices come with an increase in complexity. A startup must thus have the resources to address these complexities or risk introducing more problems than it solves.
Does it make sense to split your application?
As Sam Newman put it:
“The point of microservices is breaking an application into separate, decoupled services.”
So, before rushing to implement a microservice architecture, it is vital to consider if it makes sense to decompose an application into smaller services. You don’t want to end up with a distributed monolith and have to move back to a monolith like Istio [2] has to do, which ironically is a service mesh for microservices communication.
When a product is still young, the domain is very often unclear or uncertain, making it very hard to know upfront how the application can be decomposed into services. In fact, in Martin Fowler’s experience [8],
“Almost all the successful microservice stories have started with a monolith that got too big and was broken up.” [17]
This is precisely what Netflix [6], Uber [9], and Soundcloud [3] did. But even if you know how to split your application, it might still not justify microservices. According to Karma,
“The biggest boost from microservices is programmer productivity: you don’t have to keep the whole thing in your head!” [11]
However, if your application is small enough that you can keep the whole thing in your head, you will likely find that instead productivity decreases due to the operational overhead introduced by the microservices architecture without any substantial gain from working on smaller decoupled services. And similar reasoning can be applied to small teams to suggest microservices might not have many benefits at a small scale. This is what Segment [16] found out before deciding to transition from microservices back to a monolith.
Therefore, if it isn’t clear how work can be divided into separate domains or if the complexity of having a monolith application is manageable, the added complexity microservices introduce is generally not worth it.
Have you considered hybrid approaches?
Despite the rising popularity of microservices, startups should also be aware of alternative architectures that might better serve their objectives. The notion that monoliths are terrible and microservices are good is a misconception that emerged from the underdeveloped management of DevOps of yesteryear projects.
For project lead Steven Lemon [12], their small development team and reliance on third-party services meant that there were fewer pain points when working as a monolith. LaunchAny founder Hames Higginbotham [14] mentions a hybrid dubbed the “modular monolith”, where he explains that:
“Microservices is an extreme that is fit for a few. The trick is to find the right balance of where you leverage the complexity to make your organization more effective”.
The concept of miniservices has also recently emerged. Arnaud Lauret [15] explains that
“(…) miniservice seems to be a simpler, pragmatic way of doing microservices (…) For example, each microservice must handle its own data, miniservices may share data.”
These alternatives provide a spectrum of solutions that may be better fits and startups ought to take them into consideration instead of fixating on microservices.
Conclusion
Evidently, microservices come with their own set of complexities and requirements. The inability to properly split domains will void any benefits from the architecture. As the famous software engineering book publisher O’Reilly [13] puts it:
Adopting microservices is akin to paying off technical debt with a big “balloon payment”. It’s great if it’s done correctly, but the associated upfront cost shouldn’t be underestimated. Many microservices benefits come later in the production timeline as the projects grow larger, and not so much for newer projects.
Ross Garrett, the vice president of marketing in Cloud Elements, summed it as:
“Don’t confuse architectural perfection with business value.”
Alternative hybrid solutions like miniservices could be a better fit depending on the situation. The key is thus to identify the factors and trade-offs that best benefit your current situation.
– Hadrian Lim, Justin Chong, Pablo Gamito
[1] Beattie, O. [2016], https://monzo.com/blog/2016/09/19/building-a-modern-bank-backend
[2] Bianchi, L. [n.d.], ‘Istio is moving back to the monolith’, https://aletheia.medium.com/istio-back-to-monolith-and-you-88dd3bd23265
[3] Cal ̧cado, P. [n.d.], ‘Building products at soundcloud — part i: Dealing with the monolith’,https://developers.soundcloud.com/blog/building-products-at-soundcloud-part-1-dealing-with-the-monolith.
[4] Churchman, M. [n.d.], ‘5 reasons not to use microservices’, https://blog.runscope.com/posts/5-reasons-not-to-use-microservices
[5] Clayton, R. [2014], https://rclayton.silvrback.com/failing-at-microservices
[6] Coburn Watson, S. E. and Gregg, B. [n.d.], ‘A microscope on microservices’, https://netflixtechblog.com/a-microscope-on-microservices-923b906103f4
[7] Evans, J. [2017], https://www.youtube.com/watch?v=CZ3wIuvmHeM&abchannel=InfoQ/
[8] F ́eval, C. [n.d.], ‘When not to use microservices’, https://www.feval.ca/posts/microservices/
[9] Haddad, E. [n.d.], ‘Service-oriented architecture: Scaling the uber engineering codebase as we grow’, https://eng.uber.com/service-oriented-architecture/
[10] Jackson, J. [2018], https://thenewstack.io/debugging-microservices-lessons-from-google-facebook-lyft/
[11] Karma [n.d.], ‘How we build microservices at karma’, https://blog.karmawifi.com/how-we-build-microservices-at-karma-71497a89bfb4
[12] Lemon, S.[n.d.], ‘Howourteamcancelledourmovetomicroservices’, https://medium.com/@steven.lemon182/why-our-team-cancelled-our-move-to-microservices-8fd87898d952
[13] Loukides, M.andSwoyer,S.[n.d.], ‘Microservicesadoptionin2020’, https://www.oreilly.com/radar/microservices-adoption-in-2020/
[14] Migrating to Microservices Architecture[n.d.], https://launchany.com/migrating-to-microservices-architecture/
[15] Miniservices: A Realistic Alternative to Microservices[n.d.], https://thenewstack.io/miniservices-a-realistic-alternative-to-microservices/
[16] Noonan, A. [n.d.], ‘Goodbye Microservices: From 100s of problem children to 1 superstar’, https://segment.com/blog/goodbye-microservices/
[17] Pfleiderer, F.[2019], ‘Microservicesandwhennottousethem’, https://medium.com/digitalfrontiers/microservices-and-when-not-to-use-them-801c724d8fb0
