Last weekend, I attended the hackathon Fiction2Science of Continental. I was assigned to the Cloud Challenge where we dealt with the communication between microservices in the cloud.
The Cloud Challenge
After the official welcome, we gathered at our challenge areas with around 20 people participating in each challenge (total of 7 different challenges). Each participant indicated what his focus area is (frontend, backend or design). Based on this indication, we autonomously formed teams of four to five participants. Eventually, our team consisted of only three participants: one person focusing on design and frontend development, one developer who engaged in both frontend and backend development and me. In the beginning, I dealt mainly with backend development but eventually, I was also responsible for the presentation.
At first, we learned the technique how our developed microservices would communicate. To help with this, we had a simple tutorial with some tasks that we had to solve. Then, we tried to understand how to use our programming language to publish and subscribe to topics and how to register remote procedures and call them. We continued to solve tasks to understand these required techniques a little bit more. Having learnt these techniques, we then developed our own service by combining several microservices.
Finally, we had to present our own service in front of a panel consisting of professional Software Engineers and Innovation Managers.
The task
Initially, we selected a specific persona (the daily routine and the characteristics of this person). We investigated this persona and drafted an idea for an application that would improve her life. Our service would consist of a car interior app and a notification app used on smartphones.
The idea of our service
Our persona doesn’t like travelling alone; she sees the vehicle as a place for getting together. Therefore, we decided on developing an app where the driver could notify others, who attend the same event, to accompany her.
- This service would generate a huge amount of information about which person wants to attend which event.
- The driver would be motivated to use this app/the car in which the app runs because the car would become a place for getting together.
- Both the company running the app and the driver could profit financially because the passengers would pay a small amount of money (similar to Uber or Grab but the driver selects a certain event).
- The service could be extended to selecting a specific location the driver wants to go to.
The layout of our service
The service consists out of two applications:
- An app running on the smartphones of potential passengers, in which potential passengers would submit the event they want to attend, their own location and which would finally notify them
- A car interior app, in which the driver triggers the process of attending an event
Externally provided information would be a list with all the events, their locations and some information about them.
After the driver indicates his/her wish of attending an event (pressing the button), his/her coordinates would be transmitted and the Event List Service would return a list of events nearby. Out of the list of all the events nearby, the driver has to select an event he/she wants to attend. The selection is submitted to the backend and a list of potential passengers returned. The frontend displays them on a map. On the map, the driver could select passenger he/she wants to accompany to the event. Finally, the Notification Service sends notifications to the app that runs on the passenger’s smartphone.
We managed to integrate our microservice displaying events nearby into a service of another group. Similar to this, each microservice in a network could be used by other services as well.
Things we learned: WAMP
Our challenge dealt mainly with communication in the cloud. The technology we should learn is called Web Application Messaging Protocol (WAMP).
WAMP is a protocol used by web services to communicate with other web services. WAMP offers both communication via the publish-subscribe pattern (Pub/Sub) and communication via Remote Procedure Calls (RPC). The programming language that is used does not matter. Therefore, the microservices which are used to compose a new service could use different programming languages.
Each microservice could register remote procedures, call registered remote procedures and publish or subscribe to a topic. For publishing on/subscribing to topics or calling/registering remote procedures of other microservices they do not connect with each other but with a router. Each team was connected to a separate router running on a Raspberry Pi. Nevertheless, connecting to the router of other teams was possible as well and this allowed us to use the microservices of the other teams.
In the article Web Application Messaging Protocol, I described WAMP a little bit more detailed.
Conclusion
With an international team consisting of Ali Ariff from Indonesia, Gowtham Muthusamy from India and me, a German, the teamwork was even more interesting.
Possibly, I will use the new protocol I learned at work at FZI Research Center for Information Technology. WAMP could be applied for the communication between the existing backend and my new Python service. Though, the biggest problem might be using the Netty-based framework Autobahn|Java in Spring. Nevertheless, I will continue applying it in my private projects which you could see on my GitHub page: github.felix-seifert.com.
Aftermovie and Photos
All the photos of the event could be found HERE.