Indi’s @ Devoxx UK
This year Indivirtual’s Java team decided to visit developer related events/conferences. As part of this effort, each of the Java developers could choose an event to go to from a list of events; Devoxx UK, GoTo, IOT, Jaxx, J-Fall.
Devoxx is a developer conference that focuses on Java, Android, HTML 5 and other related upcoming/buzzword technologies. Devoxx events are also held in other cities such as Antwerp, Paris, Krakow, Casablanca and San Jose.
On 7th June we took a late evening flight from Amsterdam to Luton airport and from there an hour’s ride in a cab took us to our hotel. We stayed at The Pembury London Hotel close to Finsbury Park. It was a delight that the London weather was pleasant during our entire visit.
We reached BDS at around 9 am. After initial registration we got our conference passes that we could use for the two days. With registration process duly done, off we went to drink coffee and chat with other Devoxxians.
The talks were organised in 50 minutes slot, where each slot contained 4 to 5 talks. We were spoiled with the choices of talks, sometimes having a dilemma in choosing between two or more talks falling in a particular time slot. Below we give a brief comment on some of the talks which align with what we are doing at Indivirtual.
Benji started off with explaining about extreme programming and how it has changed over the years. He explained the key concepts and how he and his team puts it in practice in an Agile development environment.
- Mob programming
- Continuous Deployment
- Broadening Collective Leadership
- Monitoring Driven Development.
The biggest takeaway concept from this talk for us was what Benji called “mob programming” where the whole scrum team works on the same problem, on same workstation at the same time and the keyboard input task is shared among all colleagues. Although Benji and his team applies this concept regularly in their daily work, we are going to put this in practice on a case by case basis depending upon the complexity of the problem at hand.
Next, Robbert attended Paul Bakker’s talk on “Kubernetes in production – blue-green deployment, auto scaling and deployment automation”
Paul begins with explaining what is Kubernetes and why it is needed in production environment where clustered Docker containers are running. Kubernetes is an infrastructure software that works in coherence with Docker, it facilitates following :
- Scheduling Docker containers on machines
Kubernetes’ main function is to create new workers nodes and to monitor them. If one of the node crashes it will notice this and restart another node to keep fail over at the highest percentage. The power of Kubernetes lies in the mechanism to define the “state” of your container. Then it’s main goal is to keep the container(s) in that state.
To run one Docker instance on a machine isn’t difficult but to run multiple it becomes trickier since each instance wants to run the site on the same port and IP address. This in turn creates conflict and more manual work. Kubernetes has a solution for this, dynamic IP addresses. Each pod that contains a container will get a virtual IP. If you have a container that needs to talk to multiple containers on different addresses you are able to use “services” for those containers.
Kubernetes support “blue green deployment”. This way of continuous deployment has a following characteristics:
- Deployment without downtime
- Only one version is active at a time
- Rolls back on failed deployment
If a new feature is accepted, its can be pushed to a deployment branch (most likely the Master). Kubernetes will detect the change and boot up a new container with the changes, while this is happening the load balancer is still forwarding all the requests to version 1 of the container. After a successful health check Kubernetes informs the load balancer that there is a new version that is ready for accepting requests, starts the switch and finally destroy the older version. If the health check is unsuccessful Kubernetes will simply destroy the newer version, notify the webmaster that a deploy failed and leave things as they were.
If your website is under heavy/little load you can instruct Kubernetes to scale up/down at certain times or requests, this is particularly useful for websites that run in the cloud where the running cost are dynamic.
At Indivirtual we are moving towards cloud based solutions for our customers. To this end, the automation of Docker containers in tandem with Kubernetes is one of the things that will be incorporated in our development infrastructure.
Paul gave a brief introduction on modularity explaining why it’s important in writing maintainable code. In lay terms modularity is code encapsulation at architectural level. So far, till Java 8 there’s been no modularity in Java, apart from OSGi framework. Encapsulation is achieved by using access modifiers against Class, instance variables etc. Clearly, this is not enough. With Java 9 we have modularity by default “whether we ordered it or not”. Moreover, with the introduction of modules, “classpath” is removed and instead modules explicitly specify the dependencies they require and provide. And that is what Sander showed us in his live demo of JDK 9 with modules, beginning with a simple example.
With the release of Java 9 in early 2017 in mind we will be looking to run least one of our projects as POC (proof-of-concept) with Java 9 modules before the official release date. There are also other issues with migration from Java 8 to Java 9 which need to be overcome. It is also expected that Apache Maven will have Java 9 modules support in time for the official release.