Each services need to communicate with each other. And, 100 things can go wrong in that and lot of effort and fail-safe mechanisms has to be put in order for it to scale. Having said that there are lots of solutions out there but does require good amount of understanding and work
Ask HN: What's your biggest struggle with Microservices?
41–50 of 77 posts
Re: Ask HN: What's your biggest struggle with Microservices?
#42Convincing people that microservices are not a cure-all but just another design pattern. You have to start out with a monolith and only if you realise along the way that some components might work better as a service (micro or not) you should extract those. Until then, commonplace modularisation will serve you just fine. Once you have more than 1 microservice running infrastructure becomes a huge problem. There's no…
One rules of thumb is "one team one service". If you have multiple teams working on a service then it might start making sense to migrate to multiple microservices.
I would make an entirely different case.
I had a system where the main running cost was MySQL. It turned out that I needed to provision a lot of MySQL capacity because there was one table that had a high rate of selects and updates.
The hot table did not use many MySQL features and could easily be handled by a key-value store with highly tuned data structures. That's a place where a "microservice" which has it's own address space, if not machine, makes it possible to scale parts of the system that need to be scaled without scaling the rest.
Re: Ask HN: What's your biggest struggle with Microservices?
#43Management/orchestration. It's really convenient to be able to deploy things in different docker containers, and isolation, and etc., but the actual orchestration seems to be unnecessarily painful. In no particular order:
* k8s is apparently ridiculously hard to set up if you want to use something that isn't AWS / GCE / GAE / non-"big-cloud"-provider-here.
* Many of these have questionable (IMO) default authentication choices. I can understand if it's running on an internal network or something, but if you can't set up an internal / private network to hide the management interface (ex Marathon, k8s dashboard, ...) inside, you're SOL it seems. Ex. Openshift Origin having a login UI, but the default allowing logging in with basically anything you want.
* Rancher seems nice, but between the internal DNS service randomly failing all DNS queries until a full restart and rancher-server's internal MySQL server writing to the disk at 500Mbps, it's... iffy. At least it's a nice UI/UX otherwise and supports lots of authentication options out of the box.
* Straight-up not working. For example, I tried running Openshift Origin on stock Debian and Ubuntu installations, and it couldn't even finish starting up before it crashed and burned. I did file an issue against openshift/origin about this, but so far it's been unresolved. Another example with Openshift, after figuring out how to work around it failing to even start up, it can't even create pods/containers. This is apparently a known bug that's been around for a while (~4 months) with seemingly no resolution.
* Weird docker version requirements. I can get that things like k8s would want to pin to LTS versions of docker. That's fine. But if I can't even import the signing key to install the LTS docker version because it doesn't even exist in the keyservers anymore, that sounds like an issue to me.
Maybe this would be different if I was using one of the Big Cloud (TM) providers. Who knows. But with my budget of "poor college student," OSS offerings are all I can do when my entire budget is consumed by server bills - and I can't cheap out here; a few TB of bandwidth and maxing up to 16 CPU cores isn't cheap :( - and it just seems like the "state of the art" is pretty terrible, at least from the UX perspective. I spend enough time staring at text and delving into the CLI and whatnot when I'm writing software. Why is it seemingly so hard to get even a simple UI to cover the basic functionality - create a master node, add slave nodes, deploy containers, and scale them up? Rancher seems to cover this use-case the best, but I've run into enough issues with it that I'm starting to seriously consider figuring out how to write my own orchestrator. I'd rather not, since it'd be a lot of work, but setting up these "standard" tools is a ridiculous Herculean task if you don't have a massive budget, it seems.
Ninja-edit: For a bit of perspective, I'm talking about a spare-time project that ended up gaining far more users than I ever expected. I'm the only person working on it, so trying to figure out all the development, ops, etc. on my own has been a huge struggle since so many of these tools just have a god-awful UX.
Re: Ask HN: What's your biggest struggle with Microservices?
#44Convincing people that microservices are not a cure-all but just another design pattern. You have to start out with a monolith and only if you realise along the way that some components might work better as a service (micro or not) you should extract those. Until then, commonplace modularisation will serve you just fine. Once you have more than 1 microservice running infrastructure becomes a huge problem. There's no…
One rules of thumb is "one team one service". If you have multiple teams working on a service then it might start making sense to migrate to multiple microservices.
That's a pretty good rule of thumb - nice
Re: Ask HN: What's your biggest struggle with Microservices?
#45Convincing people that microservices are not a cure-all but just another design pattern. You have to start out with a monolith and only if you realise along the way that some components might work better as a service (micro or not) you should extract those. Until then, commonplace modularisation will serve you just fine. Once you have more than 1 microservice running infrastructure becomes a huge problem. There's no…
One rules of thumb is "one team one service". If you have multiple teams working on a service then it might start making sense to migrate to multiple microservices.
Agree - the biggest gain microservices give you is they allow many-teams to make progress together. If you don't have many teams then the overhead may not be worth it.
Re: Ask HN: What's your biggest struggle with Microservices?
#46We started with a monolith which made determining service boundaries that much easier. What we struggled with the most is the concept of sharing data between services. We started off with publish/subscribe method which quickly became very strenuous to maintain. Ended up switching to plain service-to-service communication over HTTP/S. This allowed us to focus on resiliency and performance of each micro-service more so…
That's why I like Foxx microservices/arangoDb - but it's really more of something you need to do from the ground up
Re: Ask HN: What's your biggest struggle with Microservices?
#47Earlier quoted context omitted.
One rules of thumb is "one team one service". If you have multiple teams working on a service then it might start making sense to migrate to multiple microservices.
I would make an entirely different case. I had a system where the main running cost was MySQL. It turned out that I needed to provision a lot of MySQL capacity because there was one table that had a high rate of selects and updates. The hot table did not use many MySQL features and could easily be handled by a key-value store with highly tuned data structures. That's a place where a "microservice" which has it's own…
I see no problem in a "monolith" using different kinds of databases.
Re: Ask HN: What's your biggest struggle with Microservices?
#48My biggest struggle is people want to use them. I can't tell you how many junior devs I've ran into who dream of every single function call becoming a distributed read/write in the message bus.
It's tough to fit this in a small comment, but I would say avoid microservices until you know they are the right solution. They are often the right solution when you have multiple teams with independent development schedules. They are often the right solution if you have daemons that have fundamentally different characteristics (web server vs message consumer).
They are often not the right solution when you decide you need another module in your app.
Distributed systems are moving parts. Moving parts break. You shouldn't have more than necessary. Deciding what "necessary" is is a pretty tough task.
Re: Ask HN: What's your biggest struggle with Microservices?
#49From my experience, there are several issues that were mostly touched by the other commenters:
* auth / authorization: easy to grasp, tough to implement,
opens a world of architectural wtfs
* service configuration files / variables
* understanding that more microservices can run on
the same host
* system entry point, credential based, jumpbox
Happy to chat more, I am definitely not an expert on the domain but for what is worth I was technical lead (whatever that means to you) on an AWS Case Study project.
Re: Ask HN: What's your biggest struggle with Microservices?
#50Earlier quoted context omitted.
I would make an entirely different case. I had a system where the main running cost was MySQL. It turned out that I needed to provision a lot of MySQL capacity because there was one table that had a high rate of selects and updates. The hot table did not use many MySQL features and could easily be handled by a key-value store with highly tuned data structures. That's a place where a "microservice" which has it's own…
I see no problem in a "monolith" using different kinds of databases.
Sure, but peeling off something that has radically different scaling properties is easier if you put a "web service" in the way.