Se ha denunciado esta presentación.
Se está descargando tu SlideShare. ×

Modern problems in backend engineering, Asko Tiidumaa


Eche un vistazo a continuación

1 de 8 Anuncio

Más Contenido Relacionado

Similares a Modern problems in backend engineering, Asko Tiidumaa (20)

Más de MobileMonday Estonia (20)


Más reciente (20)

Modern problems in backend engineering, Asko Tiidumaa

  1. 1. © 2019 TWILIO INC. ALL RIGHTS RESERVED. Micromonoliths Fixing the microservice monoliths Asko Tiidumaa
  2. 2. © 2019 TWILIO INC. ALL RIGHTS RESERVED. 7,000,0 00+DEVELOPERS 170,000 +BUSINESSES 100+ COUNTRIES WHAT IS TWILIO A software and cloud-based communications platform
  3. 3. © 2019 TWILIO INC. ALL RIGHTS RESERVED. How do we build Twilio • We believe in small, independent teams • Strong service ownership, everyone is a devops • New services and features often appear as experiments • Everything grows - feature set, teams, service count, complexity...
  4. 4. © 2019 TWILIO INC. ALL RIGHTS RESERVED. Introducing a new microservice • Build or extract the new service • Publish the client library • Upstream service adopts the library Service X Service A Service A client Service Y Service A client
  5. 5. © 2019 TWILIO INC. ALL RIGHTS RESERVED. What actually happens • Changes introduced to client library • All services to adopt the new library • ...suddenly, library with many clients • ...microservices from different
  6. 6. © 2019 TWILIO INC. ALL RIGHTS RESERVED. Getting out of a rut • Addressing issues on product level yields in less hacks • Strong service ownership and design to follow product and organisation structure Establish dependencies on functional level Identifying dependencies on functional and product level helps to identify the service or product team who should own that particular logic Use generated clients API specification published by the upstream service decreases the chances of business logic leakage. Also allows generating native clients for Java, Python, Scala… Divide and conquer Evolution just happens, line of code at a time. Prioritise splitting up services when the time is right.
  7. 7. © 2019 TWILIO INC. ALL RIGHTS RESERVED. Incentivising microservices • Reduce the cost of introducing a new service • Self-service everything • Everyone is a devops
  8. 8. THANK YOU

Notas del editor

  • GOAL: introduce myself and the topic

    This is not going to be technical, as many challenges need to be diluted by non-technical means at first
  • GOAL: describe what a twilio is

    Why does one need a twilio - we take care of the burden of protocol translation, legal requirements etc
    We make the bizarre telco protocols invisible for the customer, encapsulating the complexity behind a nice HTTP API
  • GOAL: familiarise audience with how we introduce new features, leveraging the small independent teams principle Some examples of things that have become popular (wireless), and some that are not (twilio SMSC)

    We sell trust - we should not break the customer experience with our experiments (vs facebook - go break things)
  • GOAL: describe how a new feature service or client is introduced

    It does not matter whether we use HTTP or queues to communicate internally

    Create the service/API; create the library; use the library
  • GOAL: describe the problem with logic being introduced to the client AND service

    The problem here is that the business logic for a feature owned by a team is not encapsulated within their service.
    It is now within the client library and even worse - upstream service.

    This is a problem as when one wants to change the functionality, it requires the coordination of many changes.

    Sometimes client libraries have also introduced "smart" fallbacks, totally invisible for the upstream service.

    Many microservices dependent on the libraries need to be changed. May actually be a hint of serious structural issues

    Not ALL changes are implemented within the library - downstream service specific business logic starts to leak outside of client
  • GOAL: describe OUR ways to mitigate the problem

    Establish product/functional level dependency first - may help to refactor and isolate the change

    Prefer Swagger generated clients - service team publishes only the API spec, upstream service owns implementation - java, scala, python

    Split into smaller services which are safer to bump

    Strong borders between teams - but this has a communications cost… Time difference also helps :)

    Adopting maven BOM does address part of the problem.

    Quality assurance - detect issues as early as possible
  • GOAL: describe ways of making introducing microservices easier

    admiral - create new role, comes with maven archetypes, repository and role templates

    what are the steps needed to introduce a new service/role?

    we have come a long way - security approvals etc

    Product SLA also helps to streamline strange wrinkles in the dependency graphs
  • GOAL: wrap it up, allow questions

    My email address is