Amplify Platform

DevoxxFr 2016 – Part 3

| Axway |
Devoxx France logo

For the second time, we were at Devoxx France with a booth and also several talks. Here is a compilation of what the team has attended and liked.

Day 3 – Conferences

Comment faire tourner une JVM de 16 To, par ceux qui l’ont fait by Antoine Chambille and Romain Colle

How to run a 16 TB JVM, by those who did it

Even if running such a configuration is not really a goal at Streamdata.io, I was curious about this conference. I learned that one of the biggest server you can buy nowadays is a Huawei 48TB with 576cores/8threads. The project at Quartet FS is “only” implemented on a 16TB Oracle server. The secret is that you have 3 To in heap and the rest of the memory is off heap. The way to implement your application is a bit different. You need to rewrite your code so that you only have primitive types (no more collections for instance). Besides parallelism is very complicated so you go back to a monothreaded architecture: 1 thread = 1 memory partition, use the right thread for the right processor. They implemented a NUMA architecture. They also used G1 algorithm for garbage collection which does not perform full GC but a continuous one which avoids to stuck your JVM in a full GC. As you can guess, a full GC for such a machine has only one possible ending: reboot.

I will probably never deal with that kind of machines but the talk was really instructive.

How to stop wasting your time and start performing useful code reviews by Maria Khalusova

Do you know the bus factor? How many people in a team need to get hit by a bus before the project collapses. That is supposed to make you think about knowledge sharing in your team. This is one of the advantages of a code review but not the only one. We can drop a list of some of them:

  • knowledge sharing
  • less bugs
  • ensure the features fits the specifications
  • integrate a new member in the team

For those familiar with code reviews, this talk was mainly recalling advantages and best practices such as:

  • Do not have more than 2 reviewers in the team
  • The more often, the better
  • This is not the place to initiate a tab war (yes, you know what I’m talking about!)
  • wording tact
  • precise and constructive feedback

I’m pretty sure that most of you, readers, already know and apply these practices but let’s end with two interesting points raised by the speaker. First, for those who don’t or rarely perform code reviews, be aware that performing an auto code review is supposed to remove 50% of the problems in a feature. Nice tip! With regards to the feedback written by a reviewer, keep in mind that it is always better to say “how will the application behave in such a case?” instead of “This will not work”… You could be surprised that the code was actually working and you could even learn new things looking at the solution implemented.

Last but not least, don’t forget to say “Thank you” to your reviewer, it is genuinely useful.

Micro-services IRL : ça fonctionne chez un client, on vous dit comment ! by Stéphane Lagraulet and Olivier Revial

Micro-services IRL: it works for one of our customer, we tell you what we’ve done!

This was a feedback about micro-services. When it handles with micro-services, the challenges are multiple:

  • the organization. It is the most important one! See the Conway’s law.
  • the services discovery
  • the monitoring
  • the distributed programming
  • the fail-over
  • the strategies for testing
  • the versioning / compatibility management
  • the continuous deployment

And there are anti-patterns too:

  • is a micro-services architecture really needed?
  • building a distributed monolith instead of distributed micro-services
  • using distributed transactions
  • sharing tables; CQRS (Command Query Responsibility Segregation) being the exception to this rule
  • global discovery
  • DRY

Based on their project, Stéphane and Olivier presented the tools they used to address this challenges.

  • Zookeeper has been used for the services discovery. Dedicated resources for Zookeeper is a must. You also need to clean the logs from time to time and monitor Zookeeper. One possible investigation is to use Consul instead of Zookeeper.
  • Hystrix, the Netflix Java library, for the fail-over. Hystrix implements the circuit-breaker pattern and is a good solution for dealing with the fail-over.
  • SpringCloud stack over some Netflix tools such as Ribbon and Zuul
  • Git, Jenkins, Artifactory and Ansible to deal with continuous deployment
  • WireMock and Saboteur for testing. The first one is used to mock services. The latter one to test weird errors such as network errors.
  • Spinnaker may be the next tool they will have a look at it

The slides can be found here.

Scalez de 0 à 10 millions d’utilisateurs avec AWS by Julien Simon

Scale from 0 to 10 millions users with AWS

Julien is an AWS evangelist and he was definitely evangelizing there 🙂 During his Devoxx talk, he first presented a classical web architecture which is fairly scalable but then demonstrated a very scalable serverless architecture. By serverless, he means no server instance but only a combination of AWS services (managed services + aws lambda): cloud front, rds, lambda, kinesis streams, kinesis firehose… The interesting argument is that every AWS service is very highly scalable. Since you only use AWS services with the described architecture, you automatically get a highly scalable architecture. That is true but that also means that you will have something that will tie your infrastructure with a specific provider (AWS). If you want to migrate your infra or only duplicate it to another provider, you will have to rebuild it from scratch. Think about pros and cons.

Living Documentation : vous allez aimer la documentation ! by Cyrille Martraire

Living Documentation: I’m Lovin’ It!

That was another nice talk at Devoxx. Often, you are asked to provide a documentation. But what for?

  • knowledge transmission
  • expertise
  • memory: to remember in the future

But is the doc the best way to handle these issues? The answer is no! There are alternatives.

Living Documentation

The conversations are one of them. In terms of high-bandwidth, interactivity, just-in-time, it’s a good way to share knowledge (especially with new comers). Conversation over documentation.

Pair programming and Mob programming are another way to share knowledge and get expertise. They are good ways to in-house training and get more skills.

Domain immersion (i.e. to meet and discover the domain in the real-life e.g. take in a warehouse to know how it works) enables to quickly grasp a domain. It’s a better way to get knowledge than reading a documentation that may not be up-to-date.

BDD and DDD are also good candidates. In that case, the code is the documentation. An up-to-date documentation.

In short, documentation can be replaced by many other ways to share the knowledge. The only things that must be documentation in a “EverGreen” documentation are things that never change. And there are few. All the other things should be shared by other means.

If you wish to get more insights, have a look at Cyrille’s book: Living Documentation.

3 nuances de MoM by Guillaume Arnaud

3 shades of MoM

Guillaume presented 3 MoM (Message-Oriented Middleware) during Devoxx: RabbitMQ, Kafka and Nsq.io. Knowing the first two ones, I must admit that I took few notes (sorry!). But Nsq.io arouses my interest. It’s a distributed messaging platform with decentralized topologies as paradigm. Horizontal scalability is the target. It looks like there are lots of utilities Guillaume presented and a Web Admin console. I need to find some time to investigate a bit more…

The final word about Devoxx

Devoxx France is one of the biggest developers event in France. There are always interesting and various topics, so one can find his/her interest. It’s also a good way to share knowledge and discuss about tech or methodologies with other devs, or discover new technologies. All of these couldn’t be made without the Red Coats who spend a lot of time and energy to organize this event. So, a BIG THANK YOU TO THEM!!!

This post has been written in four hands: Jean-François Marquet and Cédric Tran-Xuan.

DevoxxFr 2016 – Part 1
DevoxxFr 2016 – Part 2

**Original source: streamdata.io blog