Reactive Microservices with RxJava part 1
Microservices Issues
There are several issues with microservices, IMHO here are some:
- Operational Complexity: Microservices require DevOps and Anti-Fragility. There is some considerable infrastructure burden like have a dedicated pipeline for each service.
- Architectural Complexity: Mid-tier LoadBalancer, Discoverability, Registry, Centralized Logging, Fault-Tolerant Protocols, Dynamic Configuration are some of the new concerns MSA demands.
- Coupling: This is funny because is one of the most very first reasons to people go with microservices is have less coupling in your systems. Microservices deliver decoupling as long as defined the boundaries right otherwise you will have way more places to chance your code and this is how the coupling happens. Duplicate code is decoupled wrong contracts are not.
- No Easy Joins: When we used to have a centralized database we almost always could do a central join that goes to 3-6 tables and was any to answer pretty much any question as long as volume was not involved(assuming an OLTP scenario). There are solutions for this at scale but they are more complex most because you have more data and often different and distributed databases per services.
Should I give up?
Well, to be fair it depends on the nature of your problem and how much scale and efficiency you need to have or will need to have. I'm an SOA guy. For sake of efficiency microservices are a better architectural solution but you need be careful with the level of granularity for instance I still not sure about all this Serverless movement and maybe that's too much. Remember the Left Pad Disaster? Some folks are talking about nano-services which are the Serverless for me.
Serverless Architecture Solutions Issues
Serverless Architecture is great for mobile and IOT. I have to confess the idea is pretty awesome but in practice there are several practical issues for instance:
- Time out: I'm AWS if your function runs for more than 5 minutes will be cut off. Right now there is no long running for you.
- Availability: AWS Lambda is not available in all Regions for instance right now you can't get into Brazil / Sao Paulo.
- Back Pressure and Timeouts: There is no built-in function to deal with timeouts and back pressure.
- Warm-UP VS COST issue: AWS might there down some of your functions if take some time to people call it so well you call you will see a warm up effect and this may degrade the performance. One way to fix it is pre-warm up all the functions time to time, however doing so you will make your solution COST way more.
Because IOT and Mobile, looks like Serverless is where people are doing but this is only one part of the market, of course , is a huge part but is not everything. Right now I would not recommend run everything there. Another side effect of this is the NO OPS movement which gets stronger every day with more and more solutions like this one way to scale and make it the adoption easier. I don't need to mention there is no spec what so ever and you get a lock in easily. Meanwhile, the Enterprise companies are still fighting to slice the Monolith in the Mobile world things goes fast. Again this is a different reality with different problems.
Being Reactive
If you are optimized for efficiency that's the way to go. Reactive means using way less resources and do more with less. Reactive is not easy or for free as well. In order to have full benefits, you need to be reactive end-to-end and this is hard because is easy to have blocking code all the way from the UI to the database. Being reactive could easily imply in rewrite all your drivers. Currently, there are 2 stacks that are very mature and efficient in the sense of reactiveness which are: Akka and the Netflix Stack. Netflix is working on new stack being fully reactive and leveraging the OLD gold techniques like IPC which is pretty interesting because it goes away from the REST and goes into the Native Drivers. Async programming is hard and error-prone I'm sure you heard about callback hell. Futures are not enough because they often are blocking and lead to callback hell.
RxJava to Rescue
This code is creating an Observable from a list of primitive integers and skipping the first 2 number and taking the next 4 numbers and adding 1 to each number and in the end printing in the console.
RxJava is part of the Reactive Extensions. RxJava is a library for composing asynchronous and event-based programs without callback hell :-) using observables sequences for the JVM and Java. Rx is also known as the Observer Pattern. done in the right way. Rx works in a push model instead of pulling and it is all around functional programming which and nice and great for composition. Netflix is a huge contributor of Rx and was the one to port form .NET to Java back into 2014. RxJava does have backpressure built in(window, buffer, sample) which is very useful. RxJava has all set of functions in order to do filtering, transformations, mapping and much more. Like everything in life RxJava has issues and drawbacks for me the worst things are:
- Debugging is hard: Do the asynchronous and Parallel nature.
- Error Handling is hard: It's easy to swallow some exception and just lost the whole context.
Should I use RxJava? Yes, Definitively. RxJava has zero dependencies, it's less than 1mb and its Non-opinionated about the source of concurrency (threads, pools, event loops, fibers, actors, etc). You can find more samples in my GitHub here.
Cheers,
Diego Pacheco
