10 ms·
The key to microservices is a framework and tooling around them to make them work for you. Release management, AuthN/AuthZ, compilation, composition, service lo
by zenonu 9y ago
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.
- charlieflowers 9y agoWould 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?
- antonp 9y agoWould 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.
- ivan_gammel 9y agoYes, 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.
- sametmax 9y agoCrossbar.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.
- scarface74 9y agoRelease 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.
- deleted 9y ago[deleted]