4Developers 2018: The road to true knowledge

4Developers is one of the biggest IT conferences of its kind. I took part in the latest edition so I can tell you more about it. Let’s start with the most basic question.

What’s it all about?

Usually, on one-day conferences, we’ve got a single track to follow. If on a given time, the talk isn’t interesting for us, we’ve got no choice but to live with it. 4Developers changes it completely. At any point, there are 10 different tracks in which you can participate – starting from soft skills topics and ending with advanced systems architecture talks.

There are, of course, talks specific to a given programming language (PHP, JavaScript, .NET, Java, Python), those regarding a specific layer (Frontend, Backend), and, what’s more, there’s a special track hosted by experts from Bottega IT Minds – that’s my favorite. And, just when you start to think that’s all, you realize there are workshops too! 🙂

I am the Head of Node.js department in TSH and, because of that, I have to know a lot not only about that technology itself (patterns, libraries etc.) but also about software architecture or infrastructure. At some point in our careers, we all realize that we should focus more on how the software is created (architecture patterns, DDD, distributed systems etc.) than on frameworks or libraries. The problem is, there are not many conferences about it.

4Developers solves it – it’s like having 10 different conferences on the same day, in the same place, at the same time.

Event what?

This year I had a chance to see 6 different talks. My journey began with “Discovering unknown with Event Storming” by Mariusz Gil. This speech was a part of the Bottega IT Minds track. Spoiler alert: Bottega IT is a class of its own. Event storming wasn’t something new for me (or at least I thought so) – I never had practical experience with it, however, I had a chance to read a lot about this technique during my Domain Driven Desing-learning period.

Mariusz had a very hard task. How are you going to show event sourcing in 45 minutes, when normally it takes few-days workshops to learn it? Fortunately, before the talk began, Mariusz pointed out that this speech isn’t about learning but about inspiring us to find more about it on our own (oh, I miss my college times). And that’s completely understandable in this case.

Event sourcing isn’t about the implementation but rather about extracting the knowledge about the domain from the business.

A good understanding of it will make a big difference for a software developer, as, in the end, it’s us who have to transfer the client’s thoughts into a working implementation. Let’s keep in mind that if our ideas aren’t in sync with client’s expectations (the way he or she expects software to work), then pretty sure it won’t be a pleasure for both sides to work together.

Mariusz has guided us through the whole idea of event storming. Why do we need a wall, markers, and colorful sticky cards, and how do those cards transfer to implementation? What’s cool is that it was all backed up by a real-life example, from an event storming session he had led. To make it more interesting, a few people from that session were also present in the speech. 🙂 At the end, I have to admit – I was inspired. I’m sure we’ll try to use this approach in TSH during the next workshops with a client.

Toggle it!

The next speech was called “Feature Toggle – Zarządzanie zmianami w Continuous delivery” and it was delivered by Karol Kreft. This time, I’ve moved to the Application Architecture track. Just after I reached the room, it was clear that this is a hot topic – the place was full of people. As for me, sometime in the past, I had a chance to work with a system where I could turn on and off features.

Therefore, Karol’s talk was a chance for me to verify my approach.

It started slowly. What’s a feature branch? What kind of problems may we have if, during the development, devs are not discussing the changes they’re implementing? What’s the difference between Continuous Delivery and Continuous Deployment? When might it be worth thinking about the second one? Finally, we managed to go through all of these questions and move to what I was waiting for: how to implement feature toggles in our apps.

I wasn’t surprised when Karol started to describe the same track we followed in our case. First, we tried simple “ifs”. Then, we moved the configuration into a hardcoded file. And, after that, to a separate admin panel. Finally, Karol presented an option to refresh the whole configuration through a simple build process (for example, a job in Jenkins).

The whole speech was a good start for someone who didn’t have any previous experience with such systems.

In very simple words, it presented all the situations when we have to provide feature toggles in our applications. Yet, I’m not completely satisfied. In my opinion, it lacked info about deploying different configurations on different environments (instances). This is something we didn’t manage to implement in our project, yet could be very useful. Especially regarding A/B tests.

Show me your DDD

The, I went back to my favourite track – the one by Bottega IT Minds. Michał Michaluk and Jakub Pilimon guided us through the complex topic of Domain Driven Design – “Wprowadzenie do Domain-Driven Design na przykładach“. DDD is something I had to cope with since the beginning of my work in TSH. I also had an opportunity to mentor our developers in this field. Even though, I believed it was important for me to see how others implemented it in their software. Especially, since we’re talking about the true experts.

What was truly interesting? The whole speech was done it the form of talk between a consultant and an “old-fashioned” developer, someone who is reluctant to new approaches and thinks that we should implement all the systems using the setters and getters only. Step by step, we proceeded through the elements of the design process connected with DDD. It was not only about implementation itself – the tactical patterns – but also about strategic ones and all kind of supporting techniques. Hello, event storming, long time no see. 😉

We passed smoothly through the artefacts of the DDD system – entities, value objects, domain events, domain services etc. We also learned when to use DDD. Of course, architecture patterns shouldn’t be used in a place where it doesn’t make any sense for it. For example, ports and adapters are of no value when our app is a typical CRUD. At the same time, if something’s a core domain of our software, it’s not advisable to base implementation on ORM entities.

I really liked the form of the speech. It was fresh, I’ve never met with such an idea.

What’s more, we got a real-code example – it’s available here on GitHub. Thanks to this, we could see how a good DDD application should look like.

Houston, we have a problem

“Errors, errors, everywhere!“ was a speech by Daniel Pokusa. This one was a part of the Application Architecture track. It was also quite important for me – this time, because of the project I’m watching over.

In short, the whole speech was about patterns useful in case of error occurrence in asynchronous/distributed applications. Circuit breaker, retry, hospital queue, die, rollback and leave, bulkhead, saga, scheduler agent supervisor… Those are only a few of the techniques which Daniel mentioned.

In my opinion, it was the best speech I had a chance to see during the whole conference.

From the very start, it hit the nail on the head. Each slide showed us a new technique that may solve a concrete everyday problem. I’m 100% sure we are going to use some of them in our projects in TSH – especially in those requiring high availability.

#Serverless

What connects docker, microservices, and serverless computing? All of them are the big buzzwords of the last few years. After the fantastic speech by Daniel, I was back on the Bottega IT Minds track. This time Szymon Warda went to tell us about serverless and what it was all about – “Serverless is not about code. It is how you think“.

And I have to admit I was a little disappointed.

I was expecting code and solutions but, in the end, all I got was the definition of serverless (do not confuse with FaaS – function as a service) and the advice on how I could move my service to Azure cloud (sadly, it was only theory, not practice).

Modularity

The last speech I was waiting for was “Modularity – the final frontier“ by Łukasz Szydło. It was clear from the star that we had a chance to see someone with a lot of experience and full of interesting ideas.

In some way, this speech was an extension to the speeches by Mariusz (about event sourcing) and Michal + Jakub (about DDD). We learned that it’s almost impossible to transfer directly from a monolithic system to one based on microservices. (I don’t want to brag but this is something I had told our developers during one of the internal workshops in TSH – it’s nice to be right.) 😀

Instead of doing it directly, we should try to separate the monolith into small modules with visible boundaries and then extract them into microservice. Every other way will lead us to a distributed monolith where we have to deploy all of our 100 services together because it won’t work otherwise.

Łukasz also said one very important thing: we don’t have to follow the same template for every microservice.

We rather need to understand that each of them has a completely different responsibility, so we should apply a proper architecture pattern that fits all the requirements. Most of them are going to be tailor-made solutions – and that’s not something bad.

4Developers conference – summary

I can definitely recommend 4Developers – not only for “heads” (tech leaders) like me but, in fact, for every developer.

• 4Developers is a conference where architecture and software design topics play an essential role. And there aren’t many events like that.
• Most of the topics that you can hear about during 4Developers are something that’ll probably last for years – not a temporary fashion. I’m pretty sure every one of us will have to deal with DDD, event sourcing, or distributed systems in our work.

So, instead of being surprised, it’s much better to get prepared by taking part in the next year’s edition of 4Developers!