LinkedIn emplea cookies para mejorar la funcionalidad y el rendimiento de nuestro sitio web, así como para ofrecer publicidad relevante. Si continúas navegando por ese sitio web, aceptas el uso de cookies. Consulta nuestras Condiciones de uso y nuestra Política de privacidad para más información.
LinkedIn emplea cookies para mejorar la funcionalidad y el rendimiento de nuestro sitio web, así como para ofrecer publicidad relevante. Si continúas navegando por ese sitio web, aceptas el uso de cookies. Consulta nuestra Política de privacidad y nuestras Condiciones de uso para más información.
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 email@example.com
Modern problems in backend engineering, Asko Tiidumaa