MicroXchg 2018

MicroXchg 2018

Last week our team was at MicroXchg 2018, checking out the best that the microservices architecture has to offer.

From the simple synchronous communication to the most complex event storming, the conference offered very interesting insights.

Event driven approach for communication between microservices seems to be the most commonly used method.

Lutz Huehnken explains in his talk “Designing reactive system with event storming“, on how to design your system using events, domain driven design and commands. 

Lutz promotes the idea of focusing on the events first, describing the system in terms of the things that happen making concepts explicit and only then explore the commands that trigger these events. He emphasizes that one should not jump to conclusions, instead let the aggregates emerge from the flow of events and commands.

Service mesh is emerging as a dedicated infrastructure layer for making service-to-service communication safe, fast, and reliable

Liz Rice, Daniel Bryant and Owen Garret, mentioned how service mesh can improve the service-to-service communication by providing at infrastructure level traffic control, timeouts / deadlines, circuit-breaker functionality and others.

The idea is that a service mesh act on layers 5(session) and 6(presentation) being able to remove this complexity entirely from the layer 7(application).

Some of the options presented to help with that are:

Security is always a concern

That security is always a concern everyone knows, with the microservices architecture nothing changes in this regard. Andrew Martin showed in his talk “Continuous Kubernetes Security” how a backdoor in one of your containers can cause a big damage.

Both Andrew Martin and Liz Rice used their presentation to give some tips on how to improve your security when using containers:

  • Always apply patches on your docker images
  • Make automatic scan for vulnerabilities
  • Reduce docker image size (so you have a smaller attack surface)
  • Encrypt connections between containers

Many other topics were discussed at the conference where we learned a lot for sure. The most important thing to realize is that Pandora is in the right direction when it comes to microservices architecture.

The talks are available in the conference Youtube channel MicroXchg 2018.

Posted by carminato on 28 Mar 2018 in Architecture, Conferences, Team
Tech Stack

Tech Stack

We aim to create an environment which allows to innovate fast. Every squad can introduce new processes, tools and technologies, Continue reading →

Posted by Mathias on 14 Jan 2018 in Architecture
3 Things I Learned Extracting a Service

3 Things I Learned Extracting a Service

A few months ago, foodora’s “Search and Discovery” team extracted an elasticsearch population service from a PHP monolith (I won’t call it a microservice because our population service is still a large and complex application).

Here are three bits of advice that I wish I’d heard before we started:

1: Mark deprecations as early as possible.

Even if your internal communications are fantastic, when several teams are contributing to the code-base of a monolith it’s easy to forget what everyone is working on.

Since creating the new service might take some time (and even if it just takes one iteration of your sprint-cycle) it’s worth noting ahead-of-time that extraction work is in progress. It doesn’t take much effort to deprecate the things you’ll replace, optionally with a note about the service that will replace it and who the person / team in charge is.

This helps in a number of ways:

  • It increases the chances that anyone who has to modify or make use of any concerned classes will be aware of the upcoming change.
  • Hopefully, anyone who needs to modify or make use of the deprecated classes will keep the team creating the service in the loop know about changes that might also need to be mirrored in the new service.
  • Having a pull-request with a set of deprecations provides an easy “watch-list” for logic changes that might occur during the service development process.
  • Marking deprecations can increase your understanding of the scope and complexity of the operations that you’re trying to extract.

2: Automation will only take you so far.

In a scripting language like PHP, recursive dependency mapping can be very complex, especially with the potential for “magic” method usage, dependency injection, direct object creation, Symfony-framework containers and interface constants.

Tracing required and non-required dependencies can be easily automated with an IDE or on the command line (e.g. grepping for classes referenced with PHP’s “use” keyword). I spent some time creating scripts to help with some of the more repetitive elements of dependency tracing. While this did speed up the process of removing unused files, in the end I found that there’s no real substitute for simply going through the code that your service will replace class-by-class and often method-by-method.

This was tedious at times, but it created a much better understanding of the service’s functionality. It was also a prime opportunity for some (test-driven) refactoring.

3: Make integration tests a priority.

We started thinking about making all existing integration tests pass quite early in our development process, but I had no idea about the complexity of this task.

Next time I extract a service I’m going to try to divide this task up into smaller tickets, each of which could have been focused on more specific sub-tasks such as:

  • Ensuring existing integration tests have correct coverage.
  • Creating an area-specific (e.g. city or country) master switch to toggle old and new functionality.
  • Packaging the new service in a Docker container, perhaps even in a preliminary, “mocked” state.
  • Creating an automated process to pull down a “Dockerized” container of the service before running tests.
  • Making sure that all output, especially from error conditions, are handled correctly by the existing application.

Overall, this process provided a lot of potential for optimising the interface between the monolith and the new service as well as finding the minimum system requirements for our service.

What’s next for “Search and Discovery”?

We’re currently working on a new Scala app that will wrap the search side of elasticsearch, with a focus on auto-generation of SDKs, controllers and documentation from swagger files using tools such as Zalando’s api-first-hand. Some members of our team are actively contributing to the api-first-hand project as well. I think that’s worthy of at least one blog post, coming soon…

Posted by Stuart on 30 Mar 2017 in Architecture, DevOps, Team

Opportunistic Refactoring

Starting from scratch or opportunistic refactoring? This was the question raised recently at foodpanda when we discussed the future of our apps. Continue reading →

Posted by Henrique Rocha on 3 Mar 2017 in Android, Architecture, iOS
Architecture Guidelines

Architecture Guidelines

What are our biggest technical problems?” is something each team and especially each leader in the tech space needs to ongoing think about and address. At foodpanda all tech leads recently came together in a series of workshops to find answers for exactly this.

Continue reading →

Posted by Mathias on 25 Apr 2016 in Architecture