Should Your Company Switch To Microservices? (cio.com)

Walmart Canada claims that it was microservices that allowed them to replace hardware with virtual servers, reducing costs by somewhere between 20 and 50 percent. Now Slashdot reader snydeq shares an article by a senior systems automation engineer arguing that a microservices approach "offers increased modularity, making applications easier to develop, test, deploy, and, more importantly, change and maintain."

The article touts things like cost savings and flexibility for multiple device types, suggesting microservices offer increased resilience and improved scalabiity (not to mention easier debugging and a faster time to market with an incremental development model). But it also warns that organizations need the resources to deploy the new microservices quicky (and the necessary server) -- along with the ability to test and monitor them for database errors, network latency, caching issues and ongoing availability. "You must embrace devops culture," argues the article, adding that "designing for failure is essential... In a traditional setting, developers are focused on features and functionalities, and the operations team is on the hook for production challenges. In devops, everyone is responsible for service provisioning -- and failure."

The original submission ends with a question for Slashdot reader. "What cautions do you have to offer for folks considering tapping microservices for their next application?"

Comments

Fads, fads, fads

[Anonymous Coward]

A long time ago, management consultants figured out that changing IT architecture fads every 8-10 years and frightening VPs that they might be "left behind" created a nice stream of growing revenue. Marketing twerps cast words like "monolithic" and "legacy" into repulsive pejoratives that no cool-kid exec wants to be associated with. It's a gigantic mind-fuck designed to cause cash to fill coffers for McKinsey, Ass-Enter, PWC, Toilet-Douche, Infosyphilis, etc. Do what works for you. If it stops working, do something else.

Decision was not faulty;but design definitely was

[CraigCruden]

Sounds like you had some nutter that decided to just convert the system into microservices without much thought other than ... hey lets put them in different micro services. There are lots of ways to implement microservices, and there are a large number of ways to implement it wrong.... sounds like you fell into the second part.

And yes, you can always store the data from the the entire system on a common database or a multiple databases that you can run SQL queries across to do reporting. You can also implement a inquiry/reporting to consolidate common queries across the database -- for things like searches and reporting.

You can also implement specific domain level microservices for your business logic which collaborate with other microservices to complete the task. e.g. an order microservice for order processing which has to collaborate with the account microservice to make sure the account is allowed to do it, and a account ledger microservice where the transactions are posted when orders are completed -- all done through async messaging.

And of course all of the microservices could be hidden behind a public API service layer which routes requests etc. so that the customer does not have to know where to go.

The microservice architecture is about moving things into as small of domain specific functionality -- which should facilitate with code maintainability etc.

I would be worried about the people that got you into the mess by doing the whole thing first without first working on a subset of things and making sure that the design/architecture was correct before continuing down the road. When picking up a new paradigm -- we all tend to make lots of mistakes before actually getting it right. There are a few "right ways", and many "wrong ways" to do everything. Same with microservices.