Day 2 of JavaOne 2016 started early again and was primarily focused on microservices in my case.
Hystrix is a latency and fault tolerance library from Netflix known for its circuit breaker implementation. This hands-on tutorial session described lessons learned from preventing cascading failures in a distributed system consisting of many services. The talk explained how Hystrix works and where it helps, how to apply it to legacy code, how to use Hystrix Agent, how to monitor with Hystrix, as well as best practices for use in production.
Don’t call another Hystrix command from the catch block.
Don’t implement fallback if you don’t have a fallback, such as for logging – Hystrix will report it as success. A good use for fallback would be e.g. taking a slightly older value from cache.
Throw HystrixTimeoutException for timeouts. It indicates a potential issue with a dependency instead of a programming error.
When you add Hystrix to your code, don’t forget to update your catch blocks to account for HystrixRuntimeException.
Hystrix does not support retries. Retries inside Hystrix commands skew the metrics. Don’t retry unless necessary. If you have to do it, do it outside of Hystrix.
Minimize the use of ThreadLocal.
Don’t be afraid of reactive programming, Hystrix works fine with e.g. RxJava.
You can check out the full slides here.
As far as conference speakers go, Venkat Subramaniam is as good as they get, and his signature no-slide live-coding sessions are highlights of any Java conference. This talk was focused on design principles, high-level forces behind well-known design patterns. Venkat mentioned DRY, YAGNI, and talked in detail about SOLID (SRP, OCP, LSP, ISP, DIP). This is really great stuff every developer should know about, as it’s very helpful in understanding design patterns.
When Venkat Subramaniam comes to a conference, he really makes the most of it. This was his second session at JavaOne, taking place right after the talk on design principles. This live-coding session showed the advantages of the functional style of writing code available in Java 8 on a series of small school-like examples – prime test, line count, grouping, decorator pattern, and pythagorean triples. For each of these examples, Venkat wrote an imperative solution from scratch and refactored it to functional code, using each of the examples to illustrate a different feature or aspect of functional programming, mostly around the stream API.
This talk was about the road to Kubernetes and its use at Google. It started with a very interesting fact – Google launches 2B containers every week. That is seriously impressive. The talk continued by briefly mentioning Omega and Borg, systems at Google which affected the development of Kubernetes, before getting to explaining the basic principles of the orchestration tool and some more advanced kubectl commands for scaling and rollout.
I’ve been excited about Kubernetes for a very long time, so I decided to continue with the talks focused on this technology. In a way, this talk provided a follow-up to the previous session and focused on tooling built on top of Kubernetes, such as Jenkins Kubernetes Plugin, fabric8, Stackpoint, OpenShift and Minishift. The talk was given by Rafael Benevides and Christian Posta from Red Hat, and as such, it was focused primarily on Red Hat’s fabric8 and OpenShift efforts. For me, it was very interesting to see how far these two tools have come since my time at Red Hat and how well they integrate into the Kubernetes ecosystem now. Check them out!
Keep it simple and intuitive.
Refactor continuously. Make things better really soon.
Take reversibility of your architectural decisions into account. If a decision is easily reversible, you should make it immediately, otherwise you should postpone it to the last responsible moment.
Stick to the YAGNI design principle.
There’s no need to make things extensible at the beginning. Make them extensible when the first change comes in and creates a use case for extensibility. Being cohesive is more important initially.
Parsimony can be good. Do the absolute minimum thing you can get away with now.
Triangulate. Don’t start with interfaces and abstract classes, write a concrete class first and add abstractions when the new things you add start introducing duplicate functionality. This helps you see how the things relate and how you can extract the commonality.
Design the software to respect Postel’s law. Be generous about what you receive and conservative about what you send out.
First use, than reuse. From experience, the most reusable things don’t start as reusable, but get adapted as they’re used in new projects.
Minimize. Never build what you can download. Never download what you don’t need.
The first BoF session of the day dealt with Command Query Responsibility Segregation. More specifically, it was a case study of an application for management of activities developed internally at CERN. The application described was very simple and only managed about 1k activities for ~300 users generating ~60k events, with very little performance and scalability requirements. The most interesting part of the talk was discussion of tools that can be used for event sourcing, such as Axon, Akka Persistence, Event Store or Apache Kafka. None of these technologies were used in the case study, and the authors ended up rolling out their own custom solution based on Spring, JPA and Oracle Database.
The last BoF of the they was hosted by Jan Schäfer, the lead developer of JGiven, a new Java BDD library. The main idea behind JGiven is to address the additional maintenance cost of other BDD libraries caused by the text/HTML/wiki specifications than need to be maintained alongside the Java files. JGiven substitutes these files with an easy-to-read fluent Java API.
During the first part of the talk, I was a bit skeptical about JGiven, as its API just feels a bit strange at first. If you have previous experience with classic BDD libraries like JBehave or Cucumber, you might feel the same way. Towards the end of the talk, however, the API started to feel natural and I began to see the advantages of the approach over other standard tools. I’ve always hated the maintenance overhead of non-Java files and if I was starting a new project applying BDD, I would give JGiven a shot.
To find our more about the library, check out the slides here.
For information about other sessions at JavaOne, check out JavaOne: Day 0, JavaOne: Day 1, JavaOne: Day 3 and JavaOne: Day 4.