Speaker bio

Believer on having a beginner’s mind: eternally curious, constantly learning and being updated, passionate on what he is involved in, questioning status quo with an open mind and avoiding pre-conceptions.

Paulo A. Pereira is the Director of Engineering at Onfido. He is currently leading a team involved in reshaping a monolith into microservices, while dealing with the constraints of evolving a system where security and accuracy are of the utmost importance.

Enthusiastic about choosing the right tool for the job and combining different languages and paradigms, he is currently exploring functional programming, mainly via Elixir.

Paulo co-authored Microservices in Action and authored Elixir Cookbook He was a technical reviewer for the books Mastering Elixir, Learning Elixir and for the videos Getting Started with Elixir and Advanced Elixir and OTP.

Sessions Lisbon 2020

Paulo Alves Pereira

Microservices lifecycle

Deciding on the architecture and individual services composing your microservice powered system is just the beginning of the journey. Such architecture is prone to evolve quickly with new services being added in order to deliver new features and capabilities to your users. The real challenge is having a way to operate the system so you can, with fast pace, introduce the required changes and maintain consistency and good service level.

Microservice Architectures are distributed systems and those pose interesting challenges in the way they can be tested and how they can be monitored in order to observe what is going on.
In this session we will be focusing on techniques to increase reliability of the system and prevent cascading failures as well as some techniques to ensure all new services are created quickly and in conformity with the operational requirements, like: monitoring and metrics, error reporting, log collection, and testing.

We will briefly touch on design techniques and how to build an effective pipeline to deploy new code to production. We will also be looking at how to access data that is stored in geographically distributed data centers. We will then focus on observability so that we know both what is happening and what happened with our system and how to set monitors and alerts so we are informed about any issues before our users.

After this session attendees should have learned:

  • How to scope new services in a microservice architecture around features and capabilities
  • How to make services resilient and prevent cascading failures
  • How different testing techniques can be used to increase the quality of services and their interaction
  • How to create delivery pipelines that make it easier and safe to deploy new code to production
  • How to use traces and logs to understand what has happened
  • How to use monitors to understand what is happening
  • How to set up alerts to make sure any issues are caught quickly and with minimal impact to users

<< Back to Schedule

Microservices teams

When deciding on whether to adopt a microservice architecture every organisation tends to immediately think about tech benefits and constraints. However, systems are very much a reflection of the organisations who build them. The way teams are structured, how they own and are accountable for the systems they are responsible for is a key factor in the success of operating a microservices architecture.

Building effective engineering teams beyond a small group of people requires us to focus on the balance between autonomy and collaboration. The adoption of microservices allow our teams to deliver value faster and independently but care must be taken into guaranteeing that we don’t create silos. Instead, all teams should share a common denominator on the way they approach the day to day development and operation of the components they are responsible for.

In this session we will be focusing on the people building the software and their interactions as a key element to succeed in the adoption of micro services.

After this session, attendees will have learned:

  • How team size has an impact on communication
  • The types of teams that can be formed (Infrastructure/platform/product)
  • How to set team boundaries around their missions and roadmaps
  • How to promote knowledge sharing: chapters, guilds, rotation between teams
  • The importance of documentation and runbooks to allow knowledge sharing and team mobility
  • The need of embracing a Devops mentality: “You build it, you run it!”
  • How to setup effective on-call rotation to ensure quick response to any issues and avoid burnout

<< Back to Schedule