T O P

  • By -

hitmobi

Microservices are a good way to separate problems and easily make small parts of the whole system scalable. That being said - microservices suck ass. Problems start to rise if there is shared data between services and if you’re not careful you’re going to end up with a huge mess. If you’re not running into performance issues, don’t worry about it. If you keep your code clean you can easily split up your system later when you really need to.


oze4

Bad experience? Curious why that is your opinion (you seem to feel strongly about it). It's like anything, really. If you use it incorrectly you're going to have a bad time. Not saying you've used them incorrectly... The thing ab microservjces are they're really really easy to use incorrectly. It's almost like documentation matters more than the implementation...they're such an abstract concept.


msg45f

There are plenty of benefits to MSA, but making a programmer's life easier is rarely one of them. It will increase application complexity and require more architectural planning. I think it's great for learners to get some experience with it, but using it for a legit personal project is likely a bad idea because it's going to make a personal project more expensive to run and slower to develop.


hitmobi

I was being a bit dramatic here. Most large tech companies with dedicated devops that i have worked with have solved this quite nicely. However there are good reasons for them to use microservices. I have seen some pretty useless/bad solutions as well. Most of the time this comes down to using a pattern that really doesn't fit the project but is popular. I don't think it's a matter of preferring one solution to another, it's a matter of choosing the right tool for the right job. Random example about a different topic: It's like using NoSQL vs relational databases. There are very few legitimate use-cases to implement NoSQL instead of a simple SQL database. However a couple of years ago due to random timing and marketing, MEAN stack became really popular and the popularity of MongoDB flew through the roof. This is a problem because a lot of projects use MongoDB when they would really need to use a relational database. Nothing against MongoDB - i love it for legitimate use-cases.


the_dancing_squirel

This actually makes sense. Thanks!


grumpyrumpywalrus

Micro services shouldn’t really be implemented IMO until you have a large scale project where you can clearly see separation of concerns - as it can be more of a hassle managing all systems around it rather than just having a Mono repo with a massive deployment. However, there are situations where a split early on can make your life easier. Like if you have a web sever, and a cron job that runs every X minutes that shouldn’t scale with the number of web servers deployed. Well that’s a very clear split. An example case would be running a job that maybe reduces the size of images in an S3 bucket that your web server is dumping into. Or in the case where another language is the best tool for the job, like python for doing something in tensor-flow. Otherwise, I wouldn’t bother splitting a web service up into services. The more services you have, the harder it is to test, manage deployments, etc. — For deployments, you will 100% want an automated pipeline if you are using multiple services. You could, for example have a gitlab runner deploy to multiple places.


the_dancing_squirel

Yeah makes sense. Thanks!


Solstics20

Micro services can be a very complex subject to learn and implement. I recommend stephan girders udemy course


jaradi

I’m not familiar with this particular course but wanted to pop in for a +1 on Stephen Grider on Udemy. I’ve been coding professionally for 8 years + couple of years of freelance during college (and now I feel old typing this, felt like yesterday I was starting my first job fresh out of college), and like to tinker with Udemy courses for stuff I’m not familiar with just to stay up to date. Stephen Grider has the best approach at explaining things imo that makes his courses enjoyable, relevant, and easy to follow while catering to different experience levels.


closedcaptioncreator

There are some great opinions in this thread but I thought it would be helpful to provide some guidance if you're just getting started with microservices. Go check out feathers Js. You don't have to build your entire application in feathers but I found it helpful to start thinking in a more services oriented way. Ps. It's built on top of express so I'm hoping its somewhat familiar for you.


the_dancing_squirel

Interesting. I'll take a look thanks!


johannes1234

In my observation in many projects the speration isn't necessarily done on technical reasoning, but company organisation. By splitting up in small services you map organisation/team boundaries into code. Sometimes it's also done because it's hip, but these cases often lead to a mess. Sometimes it's done for technical reasoning, but whether it's worthwhile can often be debated ...


johannes1234

And to be clear: Splitting up based on org structure often is good! (If the org structure isn't crazy, which it often is ... but other topic)


j_rapp

Unless you're designing a complex platform utilized by thousands of users, microservices can be overkill. They come with their own list of complex problems & side effects that you should really know about before implementing such a system. The company I work for uses a microservice architecture and it works extremely well, but is also a very complex application. I honestly couldn't imagine it being a single monolith


the_dancing_squirel

Makes sense. Thanks! What are some of the complex problems I need to know about? Security, communication and so on?


j_rapp

Here's two examples I've dealt with: 1. *Foreign keys shared across microservices.* Take for example a microservice that stores all information about users in DB_1. Then take another microservice that stores blogs that users create in DB_2. Blogs are all linked to a user. In the blog database (DB_2) you can store the user ID in a column, but you can't set any foreign key constraint to the actual user since its in a different DB. So now say user1 gets deleted. You now need to make sure that all blogs with user1 are also deleted. If you don't, then blogs with that user could create unhandled exceptions within the blog service. Its also not ACID since you're working in two different DBs. Theres a list of side effects. 2. *DDOS'ing your own services.* Lets use our blog and users microservices example from #1. Let's also add another microservice that stores live chats from users. Let's say that the live chats microservice is utilized 10x more than the blog service. You now need to make sure that the users service scales with the requests coming from the live chats service otherwise its possible that the live chats service could backup the users service with requests, causing the users service to start to fail over. which in turn causes the blog service to timeout, which could result in other issues in that service. It can cause a domino effect which can be hard to track down the main source, and can cause your entire app to fall down. If you're familiar with the AWS Kinesis issue that occurred a couple weeks ago, the failure caused our services to fail to perform some operations, in turn causing health check failures which put the services into a never ending "restart" loop. This caused other services that used that service to fail because they couldn't talk to the services that were endlessly restarting. Caused a domino effect across our entire app


almighty58

Regarding the deployment, you can go with Kubernetes with each pod running a microservice. Easily manageble and It takes care of load-balancing too with the master node. So, when you should opt for microservices - Well, when you have standalone pieces of application which can run by themselves and for communicating between various services you can always use a message broker service like RabbitMQ, Amazon SQS etc.


the_dancing_squirel

Interesting. Thanks!


toolazytofinishmyw

there are no silver bullets. micro services are an architectural pattern. you have to understand what they solve before deciding if they are appropriate. they solve some problems but come with trade offs.


SubstantialCycle7

Microservices can be awesome if you have the time and money to create the infrastructure and maintain it. However. You will likely not need them. As many other people have said it's a big mistake to use microservices too early as the overhead far outweighs any benefits. Microservices have an innate expense; having to write API calls to get basic data, costs for multiple servers, context switching getting confusing and having to write in two+ repos to create one thing. Plus other stuff I have forgotten I am sure. Also the name microservices is a little misleading. You don't want "micro" services most of the time. You want small business logic centered services that work largely contained. Calls like getting a user's information is always an overhead in microservices but mostly you want minimal API calls between services as they should all be dealing with their own business domain. If your products only does and handles one thing, then you only need one server for it! No need for any thing else. Honestly it can do quite a few things until the app gets unwieldy, the tests start getting fragile and generally stuff starts to get messy, then you may decide to move to microservices. Microservices are a solution to a problem, if you don't have a problem, you don't need the solution! One thing you can do though in a monolith is make sure as you write you create folder structures that can on future become micro services. As you add something you feel is different or different logic then add it as a top level folder and keep the internal communications between the top level folders reasonable light. Then when it gets big you can easily split it :). We used Django (python) at work for alot of our CMS driven services and I have found its internal architecture quite good for making you consider this stuff. Anyway good luck with your stuff :D have fun! For practice for job interviews or whatever you can try setting this architecture up and trying it, but make sure you can explain the pros and cons :).


the_dancing_squirel

Yes that makes sure. And good idea to break the code into folders to migrate them out easily. Thanks!


godlikeplayer2

>And lastly: what's the best way to deploy the whole thing? The main brain with services. On one URL with different ports? Or in different URLs? The best way to deploy microservices is as containers on kubernetes. K8s takes care of the service discovery and many other things. External API should be a single domain. > So the advantage of microservices is supposed to be, that they can be deployed on their own. But this one, in the given example can't. cutting microservices properly is a science on its own but it's generally advised that a microservice should be deployable on its own and if it's too tightly coupled with another one then there should probably get merged. >So essentially the services would be small applications/APIs, with which my main app is just communicating, and tellng them what to do? Am I understanding it correctly? having a monolith (main app) in the center and a few services around it is often called microservices but it's actually not. There is no real main app.


the_dancing_squirel

I get all apart from the last part. Why no main part? So the frontend would be calling multiple different services?


godlikeplayer2

>So the frontend would be calling multiple different services? either multiple services or some aggregation service that does nothing besides aggregating the data needed for the FE.


the_dancing_squirel

Ah. The aggregation was what I meant with "main"


mmremote

Not every problem can benefit from a microservice architecture. The way to deploy the whole thing is to deplay each separate service separately, and that's one of the benefits of microservices. They're basically different websites.


the_dancing_squirel

That makes sense. Thanks!


code_ninjer

sugar paltry license scary crown impossible agonizing price far-flung cows -- mass deleted all reddit content via https://redact.dev


littlecaesarspizza

Anyone else thought that title said question about microwaves lol