Should Your Company Switch To Microservices? (cio.com) 118
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?"
Just makes reporting hell (Score:5, Interesting)
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.
Re: (Score:1)
But you have a whole string of the latest buzzwords and acronyms to put on your resume for your next job!
It's what your CEO approved the project.
Decision was not faulty;but design definitely was (Score:5, Insightful)
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: (Score:3)
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.
Re: (Score:2)
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 a
Re:Decision was not faulty;but design definitely w (Score:4, Insightful)
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. [despair.com]
Re: (Score:1)
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
Re: (Score:2)
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 mainta
Re: (Score:1)
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.
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
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).
Re: What is a microservice? (Score:2)
Re: What is a microservice? (Score:2)
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.
Re: (Score:2)
Then you are not running Microservices, but Micrononsense.
Re: (Score:2)
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.
And now we should all recall Fred Brook's wisdom "there is no silver bullet". The answer is: it depends. I work at company where we did exactly as you suggest and we have gigantic monolithic algorithms that have reached a level of complexity that no amount of unit test or continuous integration testing can manage the software complexity. In this case, yes we should switch to micro services. Why? Because what good is software that has high performance if it's not stable and doesn't do anything customers
Could it be a bit slow? (Score:1)
Apart from the required developers skillset, I'd look closely at the performance hit that all those TCP stacks will cause.
Jeffrey Richter's answer was pretty good (Score:4, Interesting)
He discusses the pros and cons fairly well.
Beware of strangers bearing buzzwords. (Score:1, Insightful)
What is the problem? What technology should we use to solve it?
NOT!
What cool new technology! We should use it!
Re: (Score:3)
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.
Re: (Score:2)
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.
If you listen to someone talk about something you are unfamiliar with or don't understand, it will all sound like bullshit and/or gibberish.
Re: (Score:2)
What if you are familiar with it, and it sounds like bullshit that is similar to past bullshit you already analyzed?
Oh, yeah, that would be exactly this situation. Seriously, you just walk up to somebody and assume they don't know about the subject that they made an insightful comment about? What does that say about your knowledge? It tells me you probably don't understand the words I used, or how any of them relate to the words used in summary.
Just fucking google "microservices" and find out it is literall
Re: (Score:2)
The problem is large, monolithic programs.
The technology you should use to solve it is small atomic programs.
Rather than one large program you make a lot of small programs and pipe them through to each other.
Re:Beware of strangers bearing buzzwords. (Score:5, Insightful)
"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.
Re: (Score:2)
No. The problem is that, with time, the company has built a large, unmaintenable ball of hair.
It's called Big Ball of Mud [laputan.org] actually. How Big Ball of Mud emerges as an anti-pattern is that most people are unqualified to architect software systems even ones who claim to be architects. When management doesn't have people qualified to build a system but the system must be built anyway, you get... Big Ball of Mud. If the same re-write Big Ball of Mud, you keep getting the same thing over and over again. Very few people can avoid the anti-pattern without very careful thought.
Re: (Score:2)
This sounds perfect for Agile, just use some bubble gum and stick that new thingy here as a micro-service. What, no one understands the overall structure? Ah Grasshopper, you have not imbibed enough of the kool-aid, now go back to your corner and think up a new sprint deliverable. And if we must understand how it fits into the entire system, you've done it wrong. Get ready....Sprint, Scrum, Scrum, .... , Scrum, Sprint, Scrum, Scrum, ... , Sprint, Scrum, Scrum....hey, I didn't get a harrrumph outta that guy.
Re: (Score:2)
Rather than one large program you make a lot of small programs and pipe them through to each other.
Oh you mean the opposite of systemd?
Re: (Score:2)
What cool new technology! We should use it!
Questions are no longer necessary in the post-paradigm innovative DeadOps things connected to other things world.
You just proceed directly to the answer.
It is best to combine microservices with fuzzing technologies, so when folks ask you what you are working on, you can say with straight face:
"Micro-Fuzzing!"
Fads, fads, fads (Score:5, Insightful)
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.
You change tech so you can get employees (Score:2)
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.
Re: (Score:2)
Mainframes aren't dying. IBM's mainframe division is doing well and they producing new models.
Re: (Score:1)
Mainframes aren't dying. IBM's mainframe division is doing well and they producing new models.
Correct. Mainframes aren't dying, mainframers are ... literally. At my org we're having a hell of a time staffing the maintenance of mainframe stuff we've built over decades. That's not going to get better because literally NO ONE wants to learn the mainframe since it is seen as a dead end career wise.
Re:Fads, fads, fads (Score:4, Informative)
Well, fads are what make the corporations go.
After much time in R&D, I now work at a Bank. When I joined, it was a slow 'legacy' environment... and not in a way that ensured amazing quality :P We tried changing things, but we could never get approvals.
Then the 'fads' came out. Agile, DevOps, MicroServices, The Cloud...
Sure laugh at the consultants all you like and call them fads.
What I'll say is that we've gotten the benefits.
Git = check
Jira/Confluence = check
Some Agile = check
Cloudify = check
What works to get big corporations to move are the management consultancy firms. It works. Sure, it's wasteful and if they would take 2 minutes to listen to an engineer, they could save a whole bunch...but as you say... do what works.
And fads work.
Re: (Score:1)
So it sounds like you've reorganized the deck chairs and not much else.
Re: (Score:2)
And fads work.
You're only describing the fads that stuck. Many have disappeared. You've not been in the business long enough to be able to calculate the ratio and as such are engaged in youthful, wishful thinking. When enough time goes by and you're in this field, you'll see. You might want to label me an old grumpy curmudgeon but I was just like you once, exactly like you and was trying to convince old grumpy curmudgeons the same things you are until I became one myself. Remember this 10-20 years down the read and
Re: (Score:2)
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.
Bingo and what you end up realizing is, writing commercial software isn't about writing good software, it's about making money. So... you shift your goals. If you want to write great software, you write software to make money first, amass wealth, then write whatever software you fancy in whatever way you want. You will never be able to do that working for any company.
No (Score:3)
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.
Sounds vaguely UNIX. (Score:3)
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.
Re: (Score:2)
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".
Yes, and if it's done properly it's pretty damn slick. And a lot of companies aren't just trying it, they're driving it. They're leveraging other services and supplementing it with their own stuff, and in places where it's done right it shines.
Re:Sounds vaguely UNIX. (Score:5, Interesting)
Sounds exactly like UNIX:
Developers should build a program out of simple parts connected by well defined interfaces, so problems are local, and parts of the program can be replaced in future versions to support new features. This rule aims to save time on debugging code that is complex, long, and unreadable.
Developers should write programs as if the most important communication is to the developer who will read and maintain the program, rather than the computer. This rule aims to make code as readable and comprehensible as possible for whoever works on the code in the future.
Developers should write programs that can communicate easily with other programs. This rule aims to allow developers to break down projects into small, simple programs rather than overly complex monolithic programs.
Developers should separate the mechanisms of the programs from the policies of the programs; one method is to divide a program into a front-end interface and a back-end engine with which that interface communicates. This rule aims to prevent bug introduction by allowing policies to be changed with minimum likelihood of destabilizing operational mechanisms.
Developers should design for simplicity by looking for ways to break up program systems into small, straightforward cooperating pieces. This rule aims to discourage developers’ affection for writing “intricate and beautiful complexities” that are in reality bug prone programs.
Developers should avoid writing big programs. This rule aims to prevent overinvestment of development time in failed or suboptimal approaches caused by the owners of the program’s reluctance to throw away visibly large pieces of work. Smaller programs are not only easier to write, optimize, and maintain; they are easier to delete when deprecated.
Developers should design for visibility and discoverability by writing in a way that their thought process can lucidly be seen by future developers working on the project and using input and output formats that make it easy to identify valid input and correct output. This rule aims to reduce debugging time and extend the lifespan of programs.
Developers should design robust programs by designing for transparency and discoverability, because code that is easy to understand is easier to stress test for unexpected conditions that may not be foreseeable in complex programs. This rule aims to help developers build robust, reliable products.
Developers should choose to make data more complicated rather than the procedural logic of the program when faced with the choice, because it is easier for humans to understand complex data compared with complex logic. This rule aims to make programs more readable for any developer working on the project, which allows the program to be maintained.
Developers should design programs that build on top of the potential users' expected knowledge; for example, ‘+’ in a calculator program should always mean 'addition'. This rule aims to encourage developers to build intuitive products that are easy to use.
Developers should design programs so that they do not print unnecessary output. This rule aims to allow other programs and developers to pick out the information they need from a program's output without having to parse verbosity.
Developers should design programs that fail in a manner that is easy to localize and diagnose or in other words “fail noisily”. This rule aims to prevent incorrect output from a program from becoming an input and corrupting the output of other code undetected.
Developers should value developer time over machine time, because machine cycles today are
Re: (Score:2)
"Sounds exactly like UNIX"
Because it is.
And just like the old saying goes, they are reinventing it because they forgot of it, so they are doomed to reinvent it... poorly.
For the most part, the described "advantages" come not because of microservices but because they understand better *now* what's the realm of the problem at hand. They could have done it better even with sticks and carrots for ones and zeroes and the fact that they need to invent "a new paradigm" for that, is a heavy hint that they will bri
Re: (Score:2)
Correction: it will be impossible for anybody to debug including the fools that built it because even they won't understand what they did wrong.
Re: (Score:2)
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.
Does a graphics card not do one thing but then when combined with a motherboard, CPU, case, etc. becomes a PC? Composition of smaller components to form a bigger component that works. What it requires is people who can zoom into the details and zoom out to see the big picture. Those people who can do that very well are very rare. Usually most people focus on one or the other too much or exclusively.
Re: (Score:2)
This is reminiscent of a discussion I once took part in regarding security and threats. One bright spark said we could solve the problem by going back to every machine only doing one thing. Wonderful idea...except that it is difficult to get the fighter plane off the deck and ship out of port if it a hodgepodge of single purpose, but damn secure, systems. Oh, and those communication lines? Piffle, those are easy to secure just as they did in the old days, ran dedicated wires. Ah, the good old days, it was a
Hardware is cheap. Internet access is unreliable. (Score:2)
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 metropolit
It's the data stupid (Score:2)
Data is what actually matters. Everything else is noise.
It's the future (Score:2)
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 clo
Re: It's the future (Score:2)
You're a bit late. The public cloud fad is over. It's all about in-house private "clouds" that integrate with customers' "cloud services" (think Twitter and Dropbox) without exposing the proprietary data outside of your own Software Defined Network.
Re: (Score:2)
A nation has data, trusts a US cloud to store and encrypt their data. The US brand states it will store and fully protect the data in that nation and only for that nation.
A US court then produces US court documents for the USA brand and that nations cloud data is presented in full an US open court setting?
A big, cheap, fast US cloud product is a big legal risk.
A lot of nations now have to pay in full for their own in-house option
Re: (Score:2)
I think
Re: (Score:2)
It's not just about cost and convenience, most companies are finding that between the high costs, the downtime, the poor legal protections from any EULA or SLA and the US governments (as well as Amazon and Google's) invasion into privacy affects their product and/or customers.
This isn't about a Dropbox-sized entity moving from AWS to something else (which cutting out the middle man would make sense given their scale) but smaller customers that moved to the "cloud" and have experienced too many failures, leg
Re: (Score:2)
but smaller customers that moved to the "cloud" and have experienced too many failures, legal issues or increased scrutiny are scaling back what is effectively "shared hosting" back to self-hosting or at least colocating their own 'cloud'.
I don't think the numbers back up the claim. If you look at the massive growth I think you find exactly the opposite. I'm sure there are anecdotal stories but the stats just don't bear that out.
Has anyone honestly ever been happy with the headaches of moving to Office365 or AWS (beyond the higher ups)?
No point giving you anecdotal examples, I think we just have to look at the numbers [nextplatform.com].
Do you have a source to back up your assertion that these customers are leaving these platforms in any significant numbers?
Another dumb idea to distract the ignorant. (Score:2)
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
My micro services are obsolete (Score:1)
Nano services are the next big thing. It will be game changing.
Re: (Score:2)
We are already at picoservices. Our engineering team have started looking at attoservices too. Your company is doomed, maybe you should polish that resume again.
Prerequisites (Score:4, Interesting)
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.,
Right tool for some jobs (Score:5, Informative)
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.
Betteridge law says... (Score:2)
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.
As always, context matters - good for them may... (Score:2)
...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 th
The question is wrong (Score:2)
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. Look
Should your company switch To microservices? (Score:1)
Beware some risks (Score:1)