Software Development: Are Microservices Always the Right Choice?

first_imgYesterday’s post detailed some of the benefits of microservices, like resiliency, flexibility, more controllable upgrades, the ability to blend heterogeneously created components, and better scalability. These benefits sound great. The InfoQ article notes that “De Vries argues that a monolith often is easy to deploy and run, and an architecture suitable for many applications. If something is failing, the whole applications is failing, and we know it’s failing. Most of the time we also know how to fix it, and can quickly redeploy. It’s robust and often withstands the test of time… The few microservices solutions he has come across have been quite fragile and refactored within three years after they were built.” DeVries comments that, if not properly architected, a project built on many microservices can result in “a big ball of mud”. Similarly, James Lim, Senior Staff Software Engineer at Affirm, wrote that “if an organization does not have specialized teams, it is a good idea to use a monolith. If most contributors have workflows that cut across multiple functions of a single product, forcing microservices too early will slow down the development process.” InfoQ describes a presentation by Jan de Vries, cloud solution architect, where he argues that monolithic solutions often have a lot going for them.center_img But microservices may not be a one-size-fits all. For small businesses or small projects in particular, microservices may be the wrong choice. Steven Czerwinski, Head of Engineering at Scaylr and former Google employee, said that “even though we had had these positive experiences of using microservices at Google, we [at Scaylr] went [for a monolith] route because having one monolithic server means less work for us as two engineers.”last_img

Leave a Reply

Your email address will not be published. Required fields are marked *