Modern problems in backend engineering, Asko Tiidumaa

1. © 2019 TWILIO INC. ALL RIGHTS RESERVED. Micromonoliths Fixing the microservice monoliths Asko Tiidumaa atiidumaa@twilio.com
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. © 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. © 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. © 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. © 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. © 2019 TWILIO INC. ALL RIGHTS RESERVED. Incentivising microservices • Reduce the cost of introducing a new service • Self-service everything • Everyone is a devops
8. THANK YOU

Notas

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 principleSome 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 atiidumaa@twilio.com

Modern problems in backend engineering, Asko Tiidumaa

Esté a ler uma amostra.

Modern problems in backend engineering, Asko Tiidumaa

Mais Conteúdo rRelacionado

Semelhante a Modern problems in backend engineering, Asko Tiidumaa

Mais de MobileMonday Estonia

Em destaque

Livros relacionados

Audiolivros relacionados