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

Beware of strangers bearing buzzwords.

[Anonymous Coward]

What is the problem? What technology should we use to solve it?
NOT!
What cool new technology! We should use it!

Re:Beware of strangers bearing buzzwords.

[turbidostato]

"The problem is large, monolithic programs."

No. The problem is that, with time, the company has built a large, unmaintenable ball of hair.

And then, the proposed solution has been: "hey, let's forget that large, unmaintenable ball of hair and let's substitute it with a myriad of not so big, unmaintenable (and unmaintained) balls of hair. Oh, and now that we are at it, let's add the complexity of a myriad of unmaintenable network calls!"

You can bet this is new people about to fall in all the old mistakes.

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.

Re:Decision was not faulty;but design definitely w

[Frobnicator]

Sounds like you had some nutter that decided to just convert the system into microservices without much thought other than ...

That is the thing that misleads so many people, both the non-technical bosses AND many of the technical people. We want this because it is hip and trendy, and we want it because the large companies are using it so it must be good.

Think about the headline. Walmart -- the world's largest retailer that spends more money on IT infrastructure in a single day than most companies make in annual revenue -- has switched to a product that saves their specific enormous needs a bit of resources. There are other headlines like it. Redis let's Twitter handle a million requests per second. Some large organization publishes how their enormous tech problems only experienced by the world's largest companies get some benefit. Hadoop clusters, Kubernetes, Hazelcast, memcached, Cassandra, Kafka, and more. They're great solutions if you actually have those problems the tools help with. If you're in an organization that spends a million on infrastructure then the costs of having a few of the programmers spend a few months implementing the solution can be cost effective.

Very few companies in the world have those needs, yet headlines like this make CEOs and CTOs and beancounters think they save money, and everyday tech guys want to jump in to the latest high-end technology. It doesn't matter if the database rarely hits 100 requests per minute and runs easily on a single machine, the groups decide the organization must bring in the same high-capacity infrastructure because it scales up to support the world's largest organizations. Hadoop clusters, Kubernetes, Hazelcast, memcached, Cassandra, Kafka, and more. They're great solutions if you actually have those problems the tools help with.

While some solutions are good solutions for specific needs, far too often the solutions brought in are completely wrong for the organization's actual problems.

A few companies back they had a huge internal developer group, everything was built around microservices, tiered architectures where every service , autoscaling groups, and multiple database arrays, all connected through distributed memory tools. All that for a roughly 4TB database where nearly all transactions were single-row reads; the peak was around 10,000 requests per minute (166/sec) serving out roughly 150 megabytes per minute (2.5MBps). There performance was slow, and a bit of profiling (part of my job to make things faster) revealed abysmal practices. Warnings from Sonar said strings shouldn't be reused, so in less than a second there were a million copies of the string "true". Carefully composed SQL commands were placed in interned strings, then had copies made, and copies of copies made. In several cases I found the overhead was enormous; some simple requests to generate a 50KB response would allocate 5+ MB of memory. All of it because tools suggested something might be more secure, and new-and-shiny saved massive organizations like Amazon or Twitter or Walmart a bunch of money.

When I was newly brought on and looked at the numbers, I asked my boss about it, who said they wanted to scale big just in case. A while later I had some chats with the CTO, and that was his reason as well; bring in all the latest high-end technology because when they used smaller technologies they were too slow. At that point they were looking at even bigger technologies, adding even more memory caches and renting even more expensive VM systems with terabytes of memory. As mentioned, that was one of my former employers. As the poster says: If you're not a part of the solution, there's good money to be made in prolonging the problem.