BED-Con 2019 - Conference report

BED-Con or Berlin Expert Days Conference is a yearly conference created by the Berlin Java community. The content is usually focused around Java/JVM and some frontend tech. Let me summarize a few of the best talks I have attended.

Are we worshiping complexity?

A talk by Eberhard Wolff.

The challenge: nowadays, software engineering project requirements are getting more and more complicated. That's why organizations start to scale and hire more engineers. This leads to teamwork and more engineering teams within an organization. Communication and coordination are necessary, which results in complexity.

The solution: Complexity makes us suffer. So we should fight against it. Isolated modules are one way to rescue us. In the past, these were modules or libraries. Nowadays, this is microservices. It's not only microservices, but it's also a combination of Conway's Law, Domain-Driven Design, and microservices.

Where does complexity come from?

To understand where complexity is coming from, we need to understand another concept first: Parkinson's law. Parkinsons law means that work is always expanding until the end of the given time to fulfill the task. An example Eberhard gave was the task to buy a stamp for a letter. Someone with less time will most likely buy online a digital stamp and sends the message right away. Someone with more time will take the bus to a post station, buy the stamp there and have a little trip to fulfill the same task.

Regarding engineering teams: one team is improving their services as long as they have time for it even if this time could spend more effectively on a different service.

Regarding Eberhard's talk, we have three primary sources of complexity. It's the management, the engineers, and the complexity fallacy. Let me explain what this means.

1st) Management

In this explanation, a typical manager is always striving for more budget, prestige, and power which will result in more and more people working in the area of the manager. Here both laws kick in. Conway's law makes sure the software is created around communication structures. Parkinsons law makes sure the people are all busy, even if there is not enough work for all of them. They will naturally generate some work for themselves.

From my personal experience, I do not always agree on this picture of a manager. I also have seen a different role model. But sure, there are some out there like this.

2nd) Engineers

Managers are not the root of all complexity. Engineers can build-up complexity as well.

Let's imagine an engineer who builds a new service with a fancy infrastructure. Like everything is a server-less function in a functional programming language. Whenever the engineers speak about that new service, she will get praised for this cool architecture. But nobody knows if the business value for this project is generated.

On the other hand, we have an engineer who created a new module within an existing Java service. In the end, the engineer presents her work and tells everybody that the service is performing exceptionally well and generate some additional revenue. In most organizations, there will not be high praise for archiving just the "daily job goal."

Regarding Eberhard's talk, this leads to more and more complicated codebases and architectures. In the end, managers and engineers tend to strive for the same: status. (This is not universally true, as not everyone is motivated by status. But in the cases where it is true, it will increase the complexity.)

3rd) Complexity Fallacy

Perceived complexity is always depending on your distance to the problem. From far away, everything looks easy. Let's take google.com as an example. The webpage consists of basically one input field and a search button. What could be that complicated about that?

As soon as you have a closer look at the details, you will most likely find many sub-problems, edge cases, and features that make the solution very complicated. This is often underestimated and that's the reason why complexity fallacy makes problems even more complicated.

Architecture in complex environments

Most likely, we will not get rid of the complexity at all. So we need to deal with that fact and build software that handles the complexity. When we consider these facts in our architecture decisions, we should make our software in line with the complexity constraints we got.

As soon as someone asks you to explain the architecture of your system, you should start with why. What were the constraints, and what was the goal to achieve while this architecture was agreed on? Sending this context as a prolog to the architecture explanation will help to understand why the chosen architecture was a good one.

Remote MOB programming

A talk by Jochen Christ.

Jochen spoke about how his team that is doing remote MOB programming and how teamwork can happen when everyone is far away from each other.

MOB programming is similar to pair programming, just with more than two people. Regarding Jochen’s talk, it works best with 3-4 people. Especially with four people, someone could be on vacation, and the others are still a mob instead of a pair.

The workflow how to do MOB programming is a bit different from the classical pair programming approach. In MOB programming, you get a Typist. The Typist is the one who is writing the code that the others in the mob agreed on. The Typist needs to wait until the crowd decided on a solution. The Typist is not allowed to do anything on her own. The Typist role gets rotated every 10 minutes with an automated git-based handover.

The benefits of MOB programming

As they do most often everything together they don’t need:

• Daily standup or other sync meetings
• Code review
• Handover when someone is out of office

Besides the things they can avoid, they also gained a constant momentum as nobody has to wait for another team colleague to finish something. Also, they learn from each other.

Requirements and best practices to do remote MOB programming

Before they started with their remote setup, everyone from the team and the PO came together for two weeks. In this kickoff phase, they understood the business domain and extracted the Bounded Context (a Domain-Driven-Design approach) and agreed on the technical foundation of the project.

For the remote part, they agreed on several rules to help them collaborate.

1) Remote everybody!

You can’t get a working remote setup when people start to build up local clusters. So everyone should be remote. Otherwise, it will be hard for the non-clustered remote people to follow along.

2) Camera always on!

Like in a typical office: you can see the face of your colleagues. The same should be valid for remote teamwork. So the camera should be always on. Tip: the best camera angle is from the front on the height of your eyes. This angle will lead to a most natural look.

3) Regular on-site meetings

Whiteboards, Post-Its, and meeting formats like a retrospective are most successful if you have everyone in the same room. So they meet once a month in-person.

4) Small teams

For remote MOB programming, it should not more than 3-4 developers and one PO. Otherwise, the communication overhead will be too much.

5) Same time

One of the significant benefits of remote work is to manage your time on your own and gain more flexibility. But as soon as you try to do MOB programming, everyone has to be at the computer at the same time.

6) Screen sharing

To work efficiently, everyone has to see the same things. So the Typist has to share her screen to everyone in the team. Even if the others still have a second screen to look things up. Best is to have a video conferencing tool that also supports screen and camera sharing at the same time. So they recommended Whereby or Zoom.

7) 10 minutes interval

After 10 minutes, the Typist role gets rotated to the next person. This rotation should help to have everyone engaged.

Even if you do (remote) MOB programming, you don’t always have to work together. If everyone in your mob don’t know how to proceed, it’s also fine to split apart. Read and learn how to handle the current situation and then come back together after you learned enough to tackle the problem. The same is true for trivial or monotonous tasks.

Feature Evolution in Java 13 and Beyond

A talk by Cay Horstmann

Cay, the author of Core Java, discussed the evolution of Java and how it was invented as a blue-collar worker language.

The most obvious and also the most exciting change in the JDK world is the new 6-month release train. It speeds up iterations and improvements in the language a lot as well as feedback cycles. Therefore it’s very critical that app engineers should provide feedback as early as possible to new projects and changes in the language. That’s why Cay recommended to join the Oracle Java mailing list and join the discussion about the future of Java. Besides the mailing list, it’s also a good idea to have a look at the JEP (JDK Enhancement Proposals) and feedback them. Cay mentioned that the people doing Java are no app developers, so they need some feedback from the people who are using Java in the end.

Besides the main idea of the talk, that Java app developers should engage in the language development discussions, Cay mentioned some specific interesting projects to have a closer look at. The most exciting one could be the Loom project, which seems to be a promising alternative to threads.

Service Mesh

Another talk by Eberhard Wolf was about service meshes and how they help in a microservice world. He described why a service mesh could help and dived deeper into Istio as an example of a service mesh.

Before we start and talk about service meshes, we should think about the benefits and issues of microservice architectures.

The benefits of microservices are:

• Faster time to market as codebases are smaller
• Microservices are easier to scale
• You can make a problem specific technology decision

So there are some excellent reasons for a microservice architecture. As with every solution, there are also some tradeoffs. Let’s look at the issues of microservices:

• The latency between the microservices is more significant than a local method call
• The complexity to run the whole system is way more substantial instead of running one application for everything
• No central control of your service
• Less transparency how information is flowing through the system

Regarding the talk: a service mesh should improve all issues except for the latency problem.

What is the service mesh?

A service mesh is an infrastructure component within your microservice architecture. The mesh consists of four layers. The first layer of the service mesh is a sidecar where every API call within your microservice architecture is proxied. This sidecar is deployed together with each microservice.

Underneath the first layer, we have a control plane layer, for the administration of your system.

The third layer is a collection of standard software systems to monitor your applications — e.g., Prometheus and Grafana for metrics.

The last layer is the platform where your microservices are running on. This platform could be Kubernetes. Some service meshes only support specific platforms to operate your service. So the options which service mesh you can use are limited to your container platform.

Istio is one example of a service mesh!

In his talk, Eberhard discussed what concrete tools Istio is providing and how they work together to form the service mesh.

Istio works on Kubernetes as well as on some other container platform providers like OpenShift, and it brings different tools.

For monitoring, Istio is using Grafana and Prometheus.

For tracing, it uses Jaeger, but you can also use Zipkin or others. Jaeger also provides a WebUI where you can investigate the length of a request and analyze which service took how much time to fulfill the request.

Istio uses the dashboard tooling Kiali to visualize your microservice architecture.

To test the resilience of your services, Istio includes fault injection to create errors in your service to service communication. It also provides a solution for timeouts and retries in your HTTP communication as well as a circuit breaker.

Last but not least, Istio also provides routing features to get an API gateway and security for your services with authentication and authorization. Canary releases are also supported, while you release a new version only to a few people to verify everything works fine.

Alternatives to Istio

Another option for Istio is Linkerd 2 if your container platform is Kubernetes.

Conclusion on service meshes

The pros of service meshes are:

• They solve some essential issues within a microservice architecture
• As more services you have, as more value a service mesh provides
• No code changes necessary to integrate a service mesh

The cons of service meshes are:

• Yet another technology in your production environment
• Increases latency as every request gets routed through the sidecar
• You have to change your infrastructure to set up a service mesh which will also use some of your computing resources