The Future of Asynchronous IO in Python

Post by Matthias247 » Thu, Nov 27, 2014, 12:56 PM UTC

tailhook wrote: post #30

Animats wrote: post #17

It's frustrating. Many people want an interprocess subroutine call, and few OSs have the right primitives for it. (QNX does, and Windows sort of does, but the Linux/Unix world does not.) There's an endless collection of kludges so program A can call program B implemented on top of pipe/socket like mechanisms. OpenRPC and CORBA are out of fashion. Google protocol buffers help, but don't come with a standard RPC mechan…

Do you have a link for description of how it works in QNX?

Post by anentropic » Thu, Nov 27, 2014, 1:08 PM UTC

tailhook wrote: post #29

notastartup wrote: post #4

Do we really need to reinvent the wheels? Microservice, the async craze feels like, we now need to create a single wheel that is made up of many wheels, and spend an enormous time making it look and feel like a single wheel that was working fine, never mind that it serves absolutely no difference to the end user, it will make our next few years interesting because the old way of creating the wheel is boring and unexc…

Well, here is a good article: https://plus.google.com/+RipRowan/posts/eVeouesvaVX It seems that Amazon started using microservices in 2002. Do you think 12 years is not enough to learn on mistakes?

Post by marktangotango » Thu, Nov 27, 2014, 2:07 PM UTC

Animats wrote: post #17

It's frustrating. Many people want an interprocess subroutine call, and few OSs have the right primitives for it. (QNX does, and Windows sort of does, but the Linux/Unix world does not.) There's an endless collection of kludges so program A can call program B implemented on top of pipe/socket like mechanisms. OpenRPC and CORBA are out of fashion. Google protocol buffers help, but don't come with a standard RPC mechan…

Post by rubiquity » Thu, Nov 27, 2014, 2:21 PM UTC

crdoconnor wrote: post #21

woah wrote: post #20

Earlier quoted context omitted.

Maybe I'm dumb, but doesn't splitting up a web application into micro services have many other benefits such as modularity, constraining complexity, code reuse etc.?

Modularity: No. Your headache in creating a system of micro services will just be that much greater if you don't have modular code. I wouldn't call that a benefit even if it does end up with you writing more modular code. Constraining complexity: It actually makes complexity worse (what do you do when microservice A goes down? times out? returns data you can't deserialize? takes too long?). These things you do not ha…

Post by crdoconnor » Fri, Nov 28, 2014, 3:50 AM UTC

icebraining wrote: post #33

crdoconnor wrote: post #24

Earlier quoted context omitted.

>A system which serves millions of users spans multiple machines. It's much easier to scale and evolve your stack if you're keeping it decoupled. It can be much harder. Let's say that you have a zipcode address conversion library and you're deciding whether to use it within the web stack (option A) or to create an additional service with a REST API on a separate machine (option B). Microservices! Option A means that…

I don't see why would you need to have a load balancer for the zipcode service; if the service truly scales linearly with the number of application servers, you can simply tie them together 1-on-1 with simple configuration.