SSEs even better.
29 karma · joined September 6, 2014
To start: I'd like to have seamless R/R via stateless HTTP as well as websockets. I'd like to also implement transparent push events via SSEs and the aforementioned socket transport.
Naturally, inter-service communication would use the already-present MQ.
The workflow in this true "microservices a la carte" solution would look like:
Initial, one-time setup:
1) Set up NSQ (or other supported MQ - I'll start with NSQ)
2) Set up standard, client-facing frontend servers (stateless HTTP, sockets, SSE) bound to queue.
3) Set up DNS names for frontend load-balancers (ELB, heroku load balancing, whatever) for each frontend.
---
Writing a service:
1) In your language/framework/stack of choice, create a new project, include standard-sauce, language-specific server library.
2) Write a function to do what you want. (retrieve a list of users, create a post, whatever)
3) Register/bind the aforementioned function to a specific, standard, interfaceable name (using the service library)
4) Configure service library to connect to initially-setup message broker.
The end-goal is to have a standard RPC interface, standard pub/sub interface, standard message fabric across front-end clients (browser, mobile, whatever) and back-end clients (inter-service communication).
---
Internally, a call message might look like:
{method: "get", action: "users", requestId: "21739dfe-fbeb-4da9-b698-c5720cbc488d", timestamp: "2014-12-25xxxxxx"}
This will seamlessly map to:
HTTP GET (Frontend): http://api.mydomain.com/users
Websocket message (stateful) (Frontend): {method: "get", action: "user"}
ServiceLibrary call (Ruby): "Project.call(:get, :users)"
ServiceLibrary call (Node): "project.callFunc('get', 'users', callback)"
.. and you get the idea. No prescription necessary.
---
If you like ActiveRecord, Ruby, the Rails stack: rip out ActionController, rip out Rack, use the stuff you want.
If you want to use some of the amazing JS frontend rendering toolchains: hook em up.
If you need to write a simple, highly-concurrent microservice, try Go.
Rather than prescribe an entire solution (a la Meteor, Derby, etc.), take the best tool for the job and throw it at the situation.
---
The scaling story is cool, too: if your ActiveRecord-driven microservice is unable to keep up I/O throughput, rewrite it or just spin more instances up. Totally shared-nothing in this case.
Small, widely-verified blocks of unsafe code should be the norm if unsafe code is necessary. This does not mean "if you're using unsafe you've failed!"
Or just get an American Express card (Platinum, ideally - no additional fees) and net access to the Centurion lounge and all Delta lounges (when flying Delta).
The Centurion lounge is second-to-none domestically, and the Delta lounges aren't half-bad when it comes to the free booze (some are self-serve - Jack Daniels, Grey Goose, etc.)
United's clubs are a joke comparatively.
If you're already at the point where you are utilizing compilation, why not implement a compiler-level async/await solution (probably based off of a loop + a state machine, a la regenerator).
Here's the answer:
Spawn $(nproc) more Node processes, use IPC if you need to.
Good luck seizing the theoretical performance gains one might see from threading (while not falling victim to diminishing returns related to context switching) in another comparable language.
Or any of the other top-end (in requests/sec) webservers?
Hint: they aren't utilizing green threading and/or a scheduler.
For stateless web requests (solving the C10x problem), this is not inherently bad for most applications.
> which blocks the whole app if a single function blocks
This is behavior you'll see in many other languages.
Management of execution time is very prevalent in lower-level languages. The only languages not susceptible to this problem are high-level, preemption-capable, and possess some form of green threading/scheduler e.g. Erlang/Elixir.
IMO, if you need to rely on a scheduler to help ensure that blocking doesn't occur in a disruptive fashion, you're in no position to deride those who "began as a webdevs and knows nothing better."
> asynchronous call-back hells
This is a matter of taste, opinion, and necessity.
I personally hold the opinion that "callback hell" is a symptom of poor design, and properly managed callbacks are not unpleasant to work with (I may be subject to Stockholm Syndrome).
Also, try implementing an equivalent non-blocking webserver around an event loop in a lower-level language and let me know what non-callback strategies you come up with for the coalescence of asynchronous events.
As an aside, there are hundreds of different ways to improve or eliminate the composition of callbacks in JS: emulated coroutines via generators, C#-style implementations of async/await, promises, the list goes on.
> non-functional but GC'ed language
Which functional programming languages in common use aren't garbage collected? (again: in common use)
Which other common, productive, high-level programming languages (often tasked for C10K web servers) aren't garbage collected?
What does "non-functional but GC'ed" actually mean? What does the language's programming paradigm have to do with its memory management model in this context?
> I am really too stupid to get it
- People are productive and enjoy JavaScript. - Browsers, by and large, only run JavaScript code. - JavaScript on the server-side is a very capable, battle-tested building block for performant web software. - Admittedly: JavaScript is not a great language when compared to other modern programming languages. - Aforementioned opinionated gotchas aren't enough to dissuade communities from using JS.
Is it really? Does it not potentially provide a false sense of security?
You act like someone can't (with your username and password) (automatically or otherwise) scrupulously transact on your behalf with PayPal.
If you have the username/password - in a non-MFA system - you have access to everything.
> without ... memory management
If they handled things like EBS integration, orchestration, ELB integration, and all of the usual stuff, I'd be sold in a second.
This is great work.
"in 2004" belongs in that statement.
You could probably proof it from anything but business-level error.
The biggest and most obvious threat to a lot of these hidden services are application-layer attacks.
You should not be using platforms that have the ability to do vast inspection of their runtime environment or make arbitrary outbound requests.
I'm not necessarily a fan of the "SOA-over-Tor" approach for something like a Bitcoin price: the explicitly-whitelisted bitcoin-price-checker-service communicating over a small-surface API (0MQ, Rabbit (albeit this is a bit of a larger attack surface, internally)) to another VM that has externally-terminated Tor-only outbound internet access is probably easier to work with.
I should spin up a CoreOS distribution with all guest VM outbound access turned off and try out host-level Tor termination.