This May I was lucky enough to attend the J on the Beach conference, in Marbella, Spain. The event is able to (just about truthfully) advertise itself as ‘on the beach’, but given the proliferation of ‘data’ and ‘DevOps’ conferences, did it stand out? Did it succeed in its aim of unifying us all around Big Data? And, most importantly, what does the ‘J’ stand for?
I’m afraid I still can’t answer the last question (‘Java’?) but I would probably say ‘yes’ to the other two. It was by no means a perfect conference, with some concerning issues such as very poor WiFi (I’ll return to this point) but it did manage to cover a lot of ground, and included some outstanding talks.
Tes’s Engineering Team enabled me to make this exciting trip. We encourage team members to attend tech conferences and talks. This is a very smart aspect of the team’s philosophy: it helps keep us up to date with the myriad trends and viewpoints that are always spinning out of the tech sector. The information and ideas we gain from the community feed back into the Team’s future thinking.
The sessions around the Internet of Things were excellent, with David G. Simmons’s description of a sophisticated IoT implementation on a hypothetical oil rig a particular standout. How to address the need for monitoring and heavy data analysis in a context where network access can be patchy but where accurate monitoring could mean life or death? It turns out IoT data is voluminous, even for the smallest devices, so David recommends InfluxDB. Collect the data where it’s generated, at ‘the edge’ (the rig), perform data analysis on site and then move it to the cloud on a network-available basis for more sophisticated analysis and data visualisation later.
Another interesting talk in this vein was Roland Kuhn’s example of how a factory might move away from paper, still often seen as the only reliable medium for failsafe record keeping (it doesn’t require WiFi and is readable even when it’s been crumpled up). Given the cost of machine downtime, if the internet is going to be used then event records and communication between machines need to be as resilient as possible.
How to achieve this? Create an event log that all machines can write to and read from, a constantly available source of truth. It can’t be consensus-based in case one or more machines is offline. It must be easy to synchronise with, so that machines can catch up and unload their events. Kuhn used IPFS (Interplanetary File System, literally capable of working between Earth and Mars) to store events, which are accessed via a hash known to each machine. All participating nodes regularly exchange which hashes they know about. Intriguingly, a peer-to-peer system is used for this pub/sub pattern rather than a central store.
Some sessions covered more workaday topics, like microservices: an entertainingly down-to-earth talk from Moisés Macero covered six potential pitfalls to avoid when transitioning away from a monolith. He warned about falling foul of Conway’s Law by tightly coupling individual microservices to individual teams and allocating budget accordingly; this causes difficulty later when people move around as well as preventing good communication (technical or otherwise), which is vital in the early stages when a company is implementing the new architectural style.
Moses also reported the ‘common patterns phobia’ his team had displayed, where the decoupled nature of microservices engendered a tendency to use many different stacks, and friction when a ‘common stack’ was introduced. Sometimes, though, a bit of consistency is needed in order to move fast, so if you need to introduce rules make them very clear and explain them. Gather some consensus around these decisions, and then write them down. Don’t forget to record the constraints that existed when you made the decision, or they will be forgotten within months. Not only will this provide clarity about past decisions, it will enable the team to decide later whether they were right.
I found an abundance of high quality content at J on the Beach, which made the reasonably-priced tickets worth it. I was disappointed, though, by the conference’s shortcomings, which became evident as the days went on. I already mentioned the worst, which was the poor WiFi quality (I imagine any attendee you asked would agree), which is inexcusable from a conference in the DevOps and Big Data space. I found it difficult to take notes in Google Docs because the connection kept on dropping, and during at least three of the talks the presenter was unable to demo something he or she had prepared, simply because there was no connectivity.
Aside from the embarrassing internet issues, the most worrying problem was the ease of entry into the building on the first day (which was devoted to training sessions rather than talks) - this led to the theft of several laptops. Access control is vital in applications; it’s vital in a building filled with expensive personal equipment too. More mundane issues with the conference included the tyranny of choice resulting from a timetable that featured three simultaneous talks during most timeslots, along with the lack of plug sockets for device charging and the slightly salesy nature of some of the content.
The conference was filled with unexpected, engaging content which certainly broadened my outlook, and I’m grateful to Tes Engineering for having given me the chance to attend. The far-ranging Big Data world is almost impossible to keep tabs on - J on the Beach’s was a very credible attempt, whatever the ‘J’ stood for.