After fast-forwarding through many Microservices course playlists, I've notice a

Question

After fast-forwarding through many Microservices course playlists, I've notice a

common pattern. That is, each sub-service within a given project - has a single table!

Coming from a Rails driven traditional MVC and Web-API/ SPA-Client world where I manage most of our data needs within a single database, This is new to me. Ngl, Looks like an overkill. I am more comfortable with building data model and relationships within a single database.

First Question: Is this observation correct? Do I need to split an application down even to an individual table level? What is the general rule to follow here?

Second: How do I counter the communication/ processing lag to render a response that relies on data from multiple services? It can be a big ask, I just need some direction here.

0

29.06.2021

14 ответов

17 просмотров

Roman Sharkov

Durability: What happens if your monolith fails? Right: everything fails, the entire business is down. This is really bad! If you split things up - some parts of the system might go down, for example you're unable to make orders, but you can still view and search through existing orders since those parts are operated by different microservices. Development: When you're working on a big business project, then you probably have a team of dozens of people all working on different parts of the system. Decoupling logic and data allows for better scalability and less friction during development. A microservice architecture isn't a universal solution since there's no silver bullet in software development. Sometimes when a simple monolith is the better option.

0

29.06.2021

Justin K Автор вопроса

Roman Sharkov
Durability: What happens if your monolith fails? R...

That's a strong case for microservices. I guess you have to think of frontend interface too quite differently, to hide all the disjointed data and accommodate such service failures. Going through one such tidy example would be great to pick and learn from.

0

29.06.2021

Roman Sharkov

Justin K
That's a strong case for microservices. I guess yo...

usually, I have a gateway service that clients talk to (through REST or GraphQL or similar) That gateway service has access to individual microservices. The frontend is not allowed to talk to individual services, it doesn't even know them, they're in their own network inaccessible from the internet.

0

29.06.2021

Thirteen

Roman Sharkov
usually, I have a gateway service that clients tal...

How do you scale the gateway service?

0

29.06.2021

Roman Sharkov

Thirteen
How do you scale the gateway service?

you just replicate it, which is easy to do since it's stateless

0

29.06.2021

Justin K Автор вопроса

Roman Sharkov
usually, I have a gateway service that clients tal...

Yes something like apigee or mulesoft. Interesting, I have briefly worked on one. I was referring to how a frontend written using a react component architecture would have to accommodate for service failures in such a landscape, to render a consistent sort of experience.

0

29.06.2021

Justin K Автор вопроса

Roman Sharkov
you just replicate it, which is easy to do since i...

Yes all you would really need a copy of your rules.

0

29.06.2021

Akshit

Roman Sharkov
Durability: What happens if your monolith fails? R...

Erlang/OTP primitives solve the durability problem. OTP has supervision trees, which supervise other Erlang processes and supervisors. This way Erlang does ensure durability even with a monolith. Your system will still run if one component fails. That component will be restarted according to the chosen strategy. Ofc it can't save you from a full node failure

0

03.07.2021

Roman Sharkov

Akshit
Erlang/OTP primitives solve the durability problem...

I don't see anyone rushing to write new things in Erlang tho 😅

0

03.07.2021

Akshit

Roman Sharkov
I don't see anyone rushing to write new things in ...

Well it's a nice in web services, but it's really widely used in telecom due to all the concurrency and fault tolerant stuff OTP and BEAM provides

0

03.07.2021

Justin K Автор вопроса

Akshit
Well it's a nice in web services, but it's really ...

The stuff is indeed fascinating! https://www.cnblogs.com/bozhang/articles/3153031.html

0

03.07.2021

Roman Sharkov

Justin K
The stuff is indeed fascinating! https://www.cnbl...

2013, oof, that article's 8 years old

0

03.07.2021

Akshit

Roman Sharkov
2013, oof, that article's 8 years old

The core design of OTP hasn't changed much. It worked 8 years ago, it works now :)

0

03.07.2021

jeffotoni · Accepted Answer

No and Yes, it will depend, if your model, for example if you are going to take 5k, 10k, 15k etc. of beating per req/s the correct answer is yes, if not the answer may be no. It will depend a lot on the need of the project, for what you described your projects are mostly a monolith you can have a hybrid of this there depending on the need of course. There is no general rule, there are problems and needs to be solved with an architecture that best suits reality. When you work with a distributed system, communications with FRONT whatever the web, mobile etc. it has to be via websocket or long pool or some service that will communicate with your frontend with the answers.

Похожие чаты

After fast-forwarding through many Microservices course playlists, I've notice a

14 ответов

Похожие вопросы