Slashdot Mirror
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?"
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?"
For example, we moved personal info, HR, benefits, and payroll into separate microservices. What used to be a single join now takes dozens of REST calls. It's slow to run and hard to write and verify. We regret our decision.
https://www.youtube.com/watch?...
He discusses the pros and cons fairly well.
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.
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.
All I heard was, "XML Thin Client Push Services XML Java Workstation Structured NoSQL XML New Free Blah Blah XML Blah"
If none of it is new, it doesn't even need a new word. That just proves it is snake oil bullshit and you really just need to upgrade the BOFH.
Microservices are not _the_ solution. It is a possible solution for some problems. Microservices solve various problems, but make other problems way more complicated. There simply is no silver bullet.
Unless I'm misunderstanding the article, it sounds like they want people to split their monolithic applications into smaller components that "just do one thing". However, the most important part of this process is designing the whole thing and splitting it into sets of stable APIs. If your APIs are unstable then you are just going to have an undocumented and difficult to understand system that is impossible to debug for anyone but the fools that built it.
Anons need not reply. Questions end with a question mark.
Unless you buy brand new hardware, hardware is absurdly cheap. Our hardware costs are somewhere around 1/20 of our software costs. It might even be less. I don't see any costs savings on hardware.
What I do see with "microservices" is crossing your fingers that whoever you're buying from knows what they're doing (ie: backups, non-faulty hardware, non-faulty sysadmins, etc.)
The other thing is that you have to rely on Internet access, which, in most of the US, is spotty at best. We're in a major metropolitan, high-tech area, and neither of the ISP's can provide us with reliable service. Hence, all of our software is built to run off-line during our very regular Internet outages. With "microservices", we'd just be stopped from doing any business at all every time the Internet dropped out.
The microservice architecture is about moving things into as small of domain specific functionality -- which should facilitate with code maintainability etc.
This is standard operating principal of meme machines. They say obvious things well known and understood since before most of us were born and then assert themselves as the only best path to achievement.
When picking up a new paradigm
What new paradigm? I dare you to name one new concept.
Before you can switch to microservices, you have to modularize your software along domain aspects not technical aspects. For example, do not split the system up in X-tier/layer. Instead separate the catalogue, cart, payment, adverts etc.,
"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.
If you have a task that is quick running, and has very few interdepencies, microservices may be a fit. In our case, we have file processing that needs to take place when a user uploads a file. There are a number of different websites (internal and external) from which this can happen, and implementing/updated that file processing into each of these is not very attractive.
I could use a back end service (REST or SOAP) running on a server, but to scale that up and down with demand I have to do it at the server level. Containers are an option, but I still have to provision a big enough server, or set up an auto-scaling cluster, to handle extreme scaling cases.
The microsservice solution fits nicely in this instance. In AWS Land, I can trigger a Lambda micro-server when anything is written to an S3 bucket (S3 is AWS's storage platform). As long as the processing is quick and not super-intensive, the solution is very cost effective. AWS has similar hooks all over the place, like their document database (DynammoDb).
Microservices get less attractive when you have long-running processes with lots of interdependencies. You are also at the mercy of versions of libraries and supporting utilities (like Ghostscript and ImageMagick) that are installed on the back-end. In our case, AWS took a while to update their version of Ghostscript available to Lambda which caused us some headaches.
It's also a hassle if you have big chunks of code for things like a data access layer or business logic layer. There is some overhead with an initial load of a Lambda package, and you don't have much control of when AWS decides to deallocate a package (if it goes unused, AWS frees up the resources for other things). For really big packages, this can lead to situations where you will have random performance hits. There are workarounds, like setting up a CRON to call the microservice every minute or so. If you are loading lots of supporting code, libraries or utilities, you are probably better off with containers.
At any rate, scaling at the server level (even VM) is getting less cost-attractive. Most of our new stuff is either in containers or, where it makes sense, microservices.
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.
//TODO: Think of witty sig statement