Last week I had a chance to be for the third time at a Java conference called GeeCON. I really enjoyed this event because of the number of great people and many interesting topics related to the JVM world. By visiting such conferences you can learn new things and get to know the expert’s newest opinions. However, after this event, as always, I have more questions than answers. Some mysterious magic was present there and, as software developer, I feel the need to make this magic disappear. So I have to spend some time reading articles, doing research and experimenting. In this post I want to summarize the best presentations I’ve been by those 3 days in Cracow.

Why should I provide HA for my application?

If we are creating application for some client or for ourselves we need at some point to deploy our work on production servers and expose to the world. For most cases it’s obvious that our application cannot work as one instance. We need multiple instances of our service in case of failure of one of our servers. Also the network can fail. Also the accidence of high load or some other problems which might suddenly surprise us. Therefore we have to think about High Availability much earlier just not to fail and to be awakened during the weekend.

In this post I want to introduce simple solution that allows you to keep your application architecture clean. For those of you who haven’t heard about Clean Architecture approach I recommend to read Uncle Bobs article. The main idea is to defer the decision of selecting storage engine we choose for our application, because the database is only a detail. It’s not important if it will be SQL, NoSQL or graph database. A database in our application is only the detail which should be easy to change. Premature selection of a database can have negative influence for creating our domain model. For example if we use Hibernate which is JPA implementation and we start writing code from creating Hibernate entities, it will lead us then to high coupling between our core elements and ORM framework. Postponing decision about a database can change our point of view on domain model and stop future degradation of code base.

Earlier in 2015 Red Hat made initial release of their new project called WildFly Swarm. This solution allows to run JavaEE based applications as microservices. It’s a competitor for many frameworks like Spring-boot or Dropwizard which are used for creating small application based on microservices architecture very fast. The application server now can be embedded into your application jar with all his dependencies or you can deploy your applications war into standalone WildFly application server instance as before. It’s a big step for JavaEE world and I hope that it will silence all people who were complaining about JavaEE fat application servers.

About a month ago I was at JDD conference which took place in Cracow. JDD is a two-day, Java focused, international based conference. There you have a chance to speak with many Java enthusiasts, exchange your experiences with attendees and speakers from all over the world. The conference was consisted of four parallel paths so everyone could find something interesting for himself. There were many technical lectures as well as soft topics, workshops and interactive trainings. I enjoyed the conference and I’m looking forward to the next edition.

In time of microservices, it’s relevant how we think about securing remote communication between multiple applications and how we react on network/application failure as a client. If our application depends on many external services and communicates with them remotely, it should be protected in case of network problems or unavailability of the application. One of the basic solutions is to use CircuitBreaker pattern, you can find more detailed description on Martin Fowler’s website http://martinfowler.com/bliki/CircuitBreaker.html.