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.
Apart from the required developers skillset, I'd look closely at the performance hit that all those TCP stacks will cause.
https://www.youtube.com/watch?...
He discusses the pros and cons fairly well.
What is the problem? What technology should we use to solve it?
NOT!
What cool new technology! We should use it!
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.
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.
Data is what actually matters. Everything else is noise.
The whole-abstracted "run your services and stuff in the cloud" thing will eventually be the norm, Cloud services like Azure and Amazon Web Services are basically exploding right now as they find that there are tons of advantages to it.
Even though I've turned my nose up at the whole "cloud cloud cloud" thing in the past, I'm seeing it used firsthand right now. I'm doing a contract for a healthcare services processing company (who has to meet HIPAA and PCI requirements, BTW) and all their stuff is in the cloud. All. Of. It.
Everything is done via headless servers and AWS Lambda calls customized Kubenetes containers, etc etc etc, and the only PCs they use are on their desks so they have a place to write the reams of python code that makes the whole thing go. And it does go, I gotta admit.
They save a ton of money and don't have to fiddle with any heavy hardware on the back end. They also benefit from the massive, massive AWS infrastructure that's available. (Azure is probably similar in that respect.)
Like it or not, it's the future. Heavy-weight computing power (including the infrastructure to support it) has become a commodity for all intents and purposes.
Just cruising through this digital world at 33 1/3 rpm...
Whether you use a phalanx of servers, or a bunch of old XP systems on a LAN is irrelevant. It's the QUALITY of the software that makes a difference, and quality costs money. Unless and until business executives understand that design is not a whiteboard exercise, and coding is not programming, and programming is not design, and start to develop LIFETIME budgets, they will sow these seeds of failure. Taking the lowest bid is like gambling; Looking for the most comprehensive solution IS more expansive, and it pays dividends.
Good design is focused on measurable outcomes, not how many lines of code need to be written. Outcomes like profitability, and customer satisfaction, and employee retention are not arbitrary; they are quantifiable, and lack of quantification of every milestone to the outcome is the source of most catastrophes, in my experience. I don't know how many projects I've salvaged from the "coders" by introducing the novel (it was originated in 1960!) PERT/CPM model to force the answering of "how much," "how many" and "how high" questions BEFORE a lick of code is written. Then after they've instituted some rigor, they can start forecasting resources required. SWAGs are NOT design!
It's cheap companies that contract the losers. It's those focused on the business benefits and outcomes that make it to the F500 (until they hire "quicky solution" executives).
Walmart is hardly a leader in the annals of robust development of the technology-driven enterprises.
Nano services are the next big thing. It will be game changing.
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.,
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.
based on what they're trained in; and they're trained in whatever's cheapest. That's why mainframes are dying. It's expensive to train, especially if you're doing it in India. That's the same reason Java took off.
The tech is only part of the cost. It's not even the biggest part. Employees are always the big cost and anything that drives down those costs will be weighted heavily.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
Nothing really. You can put the microservices into containers and VMs, or have some of them be from cloud services. That part is new(ish).
No. You shouldn't. Devops is for companies that want to automate pushing dev-branch to stable without as much as a code review. Microservices are great to preview a piece of software or develop against a consistent reusable base but I've never seen good things from Docker and co in production.
Custom electronics and digital signage for your business: www.evcircuits.com
Where the hate comes for SQL joins I never got. You are throwing away evey optimization and advantage of database research over 50 years cause the young'uns wanted something more hip.
Finally the NoSQL cancer has spread to networks and architectures.
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
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
So it's like a distributed object system, only terribly complicated and cumbersome?
Ezekiel 23:20
You know, there is an actual name for things that access a database (any database, shared or not) and implement some domain specific logic. They are called programs.
'Micro service' is yet another silver bullet and it solves precisely dick if it is used as part of a push towards it rather than being used once in a while when it makes sense (and would always make sense whenever people decide to write a new program).
Here is the actual reason people jump from one silver bullet to another cyclically: programs grow, the developers move on, time passes, requirements grow and change, documentation gets stale, nobody remembers what it is anymore, management changes and developers move on into architecture and feel the need to differentiate themselves with something buzzwordy.
Any 'micro' service will eventually do more and more to manage requirements, the communications between 'micro' services is just like communications between any services within a monolith, only more expensive to maintain.
All of this follows normal rules of entropy, there are no silver bullets and everything new is repackaged old.
Something to consider: if evolution of our bodies used micro services, would we have eyes running separately from our heads with their own tiny feet?
You can't handle the truth.
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.
Bingo. This is the problem with discussing patterns. Many developers (even architects), even incredibly highly educated and intelligent ones are still stuck in the mindset of the "the one pattern/architecture to rule them all". That, in and of itself, is evidence of lack of sufficient experience and that the person has not achieved seasoned Journeyman status. There is no one magic pattern to rule them all that if we practice it religiously we will always write highly scalable, performant, easy to maintain code. Anyone who says otherwise is a fool and if someone made that statement in a job interview with me, they would not get the job because I know their wishful thinking will generate crappy software most likely. How do I know that? Because when I was younger I did the same thing and I watch people do it all the time.
After I learned from all those mistakes I progressed to Journeyman status and architected a highly available (99.999% update) system that achieved all of the things I mentioned above. Was there any one single pattern or practice followed that achieved that? Well, yes, if you consider using your brain to use the right tools/patterns/etc. for each part of the town map. Otherwise, no.
I've been on job interviews where I didn't progress because of things like "you didn't use enough interfaces". Really? I've written real deployed enterprise level code that processes millions of transactions per day without crashing and processes each transaction in milliseconds and you're going to tell me this? You've never achieved anything in your life. Yes my system used interfaces but it used them where appropriate. In that case, where I wanted polymorphic behavior and wanted to allow a third party to provide an entire implementation if they so chose. You don't use something for the sake of using something as if you get points every time you use [insert thingie here]. That's not how good software is written that stands the test of time.
We'll make great pets
...not be good for you.
If this type of separation of concerns works for you, then use it. I would argue that your architecture was poorly designing in the first place if you find yourself having to do this.
The biggest caveat? Be careful that you don't microservice and simply scale up your single points of failure.
We had an engineering group break up a monolithic worker, not because they couldn't scale workers, because the lead read a book/article (I forget) from 2006 talking about how microservices are the answer to everything.
The only problem was that each of his microservices depended upon a previous service (not feeding off a queue) and when one went down, they all went down. Usually in the one not well instrumented ;). Ops wasn't particular happy about this either as it made deployment, maintenance, testing, and other issues more difficult/complicated when there was no discernible benefit (it didn't let us change our instance sizes like in the article.)
Again, it may be exactly what you need - it may not. Make sure it's right for you.
Loading...
I agree, and I am a big proponent of service architectures, and yes, I force myself to use the term "microservices" because it seems to be the popular one these days.
There isn't anything new about service architecture. You put a network call in between two pieces of code and suddenly you need a queue for the interface to be robust. Once you put a queue in front of code, you're handling messages, and in particular, you're handling messages that can arrive more than once. So you need to ensure your handlers are idempotent. Then you need to stitch together a reporting database of some kind to serve queries that supply the data for the UI. Which should mean that your services publish events -- pub sub is another pattern that has been around for a while. All of that work wins you the ability to compose a large, complex system out of very loosely coupled, autonomous pieces. When it works, it's great. It usually doesn't, however, because teams don't have the maturity, habits, or expertise on hand to see such a project through to completion.
Nothing about it is "new," except to the inexperienced web programmers I coach who don't really understand service architecture -- who also usually believe that you can achieve microservices just by taking parts of your existing system and putting a web interface around them. Sigh.
All that to say, there are some definite benefits to service architecture that shouldn't be discounted just because "microservices" is yet another tech trend to have been fed through the meme machine.
Slashdot: Where people pretend to be twice as smart as they really are by behaving like children.
One cannot say if a certain technique is good for a company without knowing what problems it should solve.
If you consider something, learn about it, think about it, make a primitive prototype. If you still think it's suitable for your needs, use it. If your prototype ends up as a complex mess of code, look somewhere else.
The company I work with deals with a rather large >100 million dataset database. It's the portability database of Germany and contains the carrier for every phone number in Germany. Lookups happen via a small program coming with Kamailio. (probably the best part of that) Updates, however, happen via a very simple shell script utilizing standard Unix tools, or faster alternatives to it. (uniq can be very slow) Data is kept in a plain text file, and a complete update takes much less than half an hour.
Yet more of the Cloud .. the Cloud .. the Cloud, instead of paying the one off for your own servers, you pay a yearly rent, in the cloud .. in the cloud ...
In theory doing microservices is OK, but there are some huge risks (I'm seeing it in real-time with a couple of big customers). Beware isolated copies of data behind the microservices. There is too much "academic pontification" here coming from some Architects. Is your organization really ready to keep data in sync between a microservice's representation of that data and the System of Record's (SoR) representation of that data? How good is the code? This gets messy quickly. What are you going to do when (not if, but when...) the data gets out of sync between the multiple representations? If you're doing a financial system then how will you achieve compliance? Dependencies. Micro means more things. Who needs what? How do you manage change? One customer is testing a tool called 8folios to help with this.
Using interfaces with a single implementation is MORE code maintenance!
If you have multiple implementations, then refactor into an interface (which is trivial with the right tools), but until then keep it simple, stupid.
Your rant seems to completely neglect the small matter of code maintenance and extension. So yeah, there is a good reason for using interfaces and abstraction even if during your tenure you only expect to have one implementation of a specific thing.
You can say what you want, my system has been running, easy to maintain and has a proven track record of 15 years. What do you have? A bunch of theoretical nonsense. That's what you have. Look when you have a hammer, everything looks like a nail. And that's your problem. Some of us never learn. I hope you do.
We'll make great pets
Using interfaces with a single implementation is MORE code maintenance!
If you have multiple implementations, then refactor into an interface (which is trivial with the right tools), but until then keep it simple, stupid.
Correct! You sir are obviously a seasoned programmer. Cheers! FWIW - back in ye olden days we didn't have refactor tools that allowed us to do it in a few clicks. We had to do this all meticulously by hand but we still did it anyway. And we also had to walk uphill in the snow both ways to school too. :P
We'll make great pets