News for hackers. Stuff that matters.
Re:The Death of Microservice Madness in 2018 by zenonu on Sunday January 21, 2018 @08:29PM (#16201211)
The key to microservices is a framework and tooling around them to make them work for you. Release management, AuthN/AuthZ, compilation, composition, service lookup, etc. should all be "out-of-the-box" before microservices should ever be considered. Otherwise the O(n) gains you get in modularity turn into O(n) FML.
Re:The Death of Microservice Madness in 2018 by charlieflowers on Monday January 22, 2018 @01:33AM (#16202333)
Would love to hear some peoples' thoughts on good contenders in each of these areas. What are some good boxes to get these out of in 2018?
Re:The Death of Microservice Madness in 2018 by sametmax on Monday January 22, 2018 @06:21AM (#16203521)
Crossbar.io is currently an interesting approach IMO.

It does have a single point of failure that is also a bottleneck (the router) and it's a lot of work to load balance / failover it.

But other than that, it provides a fantastic way to make microservices:

- anything is a client of the crossbar router. Your server code is a client. The db can be a client. The web page JS code is a client. And they all talk to each others.

- A client can expose any function to be called remotely by giving it a name. Another client can call this function by simply providing the name. Clients don't need to know each others. Routed RPC completly decoupled the clients from each others.

- A client can subscribe to a topic at any time and be notified when anothe client publishes a message on that topic. Quick, easy and powerful PUB/SUB with wildcard.

- A client can be written in JS (node and browser), Python, C#, Java, PHP, etc. Clients from other languages can talk to each others transparently. They all just receive JSON/msgpack/whatever and error are propagated and turn into the native language error handling mechanisme transparently.

- The API is pretty simple. If you tried SOAP or CORBA before, this is way, way, way simpler. It feels more like using redis.

- It uses websockets, which mean it works anywhere HTTP works. Including a web page or behind a NAT or with TLS.

- Everything is async. The router handles 6000 msg / s to 1000 clients on a small Raspberry Pi.

- The router can act as a process manager and even a static / wsgi web server.

- you can load balance any clients, hot swap them, ban them, get meta event about the whole system, etc.

- you can asign clients permissions, authentications, etc. Sessions are attached to each connexion, so clients knows what other clients can do.

Re:The Death of Microservice Madness in 2018 by scarface74 on Monday January 22, 2018 @06:49AM (#16203679)
Release Management. It's not what the cool kids are doing but Microsoft's Visual Studio Team Services is the easiest CI/CD solution I've ever used.

Service Lookup - Hashicorp's Consul.

Authorization/Authentication - I've played with Hashicorp's Vault. It seems overly complicated but the advantage is that it doesn't tie you to a single solution and it can use almost anything as a back end. I haven't had to solve that problem yet.

Re:The Death of Microservice Madness in 2018 by antonp on Monday January 22, 2018 @04:30AM (#16203084)
Would like to echo this request.

Had to implement a micro-service architecture in python about a year ago and was jealous of my Java colleagues who (so I heard) have great ecosystem for enterprise service discovery, messaging etc.

Re:The Death of Microservice Madness in 2018 by ivan_gammel on Monday January 22, 2018 @05:23AM (#16203310)
Yes, we do. The ecosystem is great and microservice architecture may be manageable even in small teams, but it's always a process that defines the success. From my own experience, the biggest technical problem of microservices in Java can be the performance of the whole system (in a monolith there's much less logging and state management, no network latencies and mismatching parallelism settings). Discovery, auth, messaging, configuration management etc are solved.