Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Microservices – Demo Project in Python

github.com

Post reply on HN
Print view View original

11–20 of 21 posts

Re: Microservices – Demo Project in Python

#11

Post by kpmah »

nickknissen wrote: post #10
kpmah wrote: post #7

Number 1 problem with microservices here: https://github.com/umermansoor/microservices/blob/master/ser... N+1 HTTP requests. Ouch. Wouldn't it be nice to be able to do a database join?

or just retrieve a list of movies movies_resp = requests.get("http://127.0.0.1:5001/movies?id=1&id=2&id=3")

Right, so you implement this multi-get for every service, you work around the GET URL length limit by using POST or something, you do this slow HTTP join in parallel with any other service data you need if possible, in your application code, and you get what a single SQL JOIN gives you.

Re: Microservices – Demo Project in Python

#12

Post by peterhunt »

kpmah wrote: post #7

Number 1 problem with microservices here: https://github.com/umermansoor/microservices/blob/master/ser... N+1 HTTP requests. Ouch. Wouldn't it be nice to be able to do a database join?

There's a lot of benefits to this approach over a database join if you have async IO. Specifically, sharding becomes trivial and you can cache each movie individually, so if one movie changes you don't need to invalidate the cache for all of them.

Re: Microservices – Demo Project in Python

#13

Post by kpmah »

peterhunt wrote: post #12
kpmah wrote: post #7

Number 1 problem with microservices here: https://github.com/umermansoor/microservices/blob/master/ser... N+1 HTTP requests. Ouch. Wouldn't it be nice to be able to do a database join?

There's a lot of benefits to this approach over a database join if you have async IO. Specifically, sharding becomes trivial and you can cache each movie individually, so if one movie changes you don't need to invalidate the cache for all of them.

Yes, it might make sense if you're Facebook or Amazon to do this stuff. For the rest of us, a single (reasonably optimised) database can scale up to thousands of hits per second. Probably more.

Also there's another downside to this approach: you lose the ability to do atomic transactions on the application's data.

Re: Microservices – Demo Project in Python

#15

Post by peterhunt »

kpmah wrote: post #13
peterhunt wrote: post #12

Earlier quoted context omitted.

There's a lot of benefits to this approach over a database join if you have async IO. Specifically, sharding becomes trivial and you can cache each movie individually, so if one movie changes you don't need to invalidate the cache for all of them.

Yes, it might make sense if you're Facebook or Amazon to do this stuff. For the rest of us, a single (reasonably optimised) database can scale up to thousands of hits per second. Probably more. Also there's another downside to this approach: you lose the ability to do atomic transactions on the application's data.

Sure, but if you ever need to shard, you can no longer assume you can do atomic transactions anyway, which means you need to rewrite a lot of stuff.

By designing in this way, your scaling problems change from "the entire app fell over" to "the movie service fell over", which really helps with availability.

Not that there aren't disadvantages with microservices (overhead, distributed tracing, etc), I just think app architecture isn't one of them.

Re: Microservices – Demo Project in Python

#16

Post by Endurance1 »

Hello for everyone! Here are new great gadgets!Would you please tell your opinion about them.Had you ever used some similar devices?Thanks for everyone!

Lasers and engraving machines made by Endurance. https://youtu.be/GzUtTyspTgQ

Endurance SelfieBot. Smart gadget that connects hearts. https://youtu.be/ccFt0MII1uc

Here the official wedsite of the greatest Russian American company that is specializing in development and sales of high technology production, mainly, lasers, diode laser engravers, telepresence robots and robotized systems declares the pre-seed round of investments attraction to the project closed.

http://endurancerobots.com/about-endurance/

Re: Microservices – Demo Project in Python

#17

Post by prince_af_123 »

zepolen wrote: post #5

This shows a few of the drawbacks of microservices one of which is memory. This project used about 15mb per python instance = 60mb total when the entire stack is launched. Once you load a few largish python libraries like sqlalchemy you can get up to 100mb per instance x 4 = 400mb. What would be interesting is a framework that allows you to run the entire microservice stack in a single interpreter (shouldn't be hard…

> What would be interesting is a framework that allows you to run the entire microservice stack in a single interpreter (shouldn't be hard with flask blueprints) and break off the subapps as necessary when the need arises.

The idea behind microservices is to have small services running on their own processes and communicating using a light-weight mechanism. This means you could write a service in Java, another in Python, Node.js etc. (i.e. pick the most appropriate language for the task)

Re: Microservices – Demo Project in Python

#18

Post by newman314 »

zepolen wrote: post #6
newman314 wrote: post #4

Earlier quoted context omitted.

Firewall != AAA != encrypted transport They have different usages; I wouldn't say one is more secure than the other.

For interservice calls a firewall is much more secure than any auth system, way less vectors of attack. Encrypted transport on public networks should be a given anyway, although if you have a private network then that is unnecessary also. The only place auth is needed is for services that interact with users, and that works well in the microservice philosophy having an auth service which talks to all services as in u…

I disagree.

Given what we now know post Snowden, it's certainly advisable to encrypt internal transports whenever possible.

As an additional example, lots of people tend to mistake MPLS as being encrypted as opposed to just being a private network so it's definitely advisable to make sure traffic is encrypted whenever possible inside or out.

Re: Microservices – Demo Project in Python

#19

Post by zepolen »

newman314 wrote: post #18
zepolen wrote: post #6

Earlier quoted context omitted.

For interservice calls a firewall is much more secure than any auth system, way less vectors of attack. Encrypted transport on public networks should be a given anyway, although if you have a private network then that is unnecessary also. The only place auth is needed is for services that interact with users, and that works well in the microservice philosophy having an auth service which talks to all services as in u…

I disagree. Given what we now know post Snowden, it's certainly advisable to encrypt internal transports whenever possible. As an additional example, lots of people tend to mistake MPLS as being encrypted as opposed to just being a private network so it's definitely advisable to make sure traffic is encrypted whenever possible inside or out.

Good point.
Post reply on HN