Modern problems in backend engineering, Asko Tiidumaa
Download as PPTX, PDF0 likes395 views
This document discusses how microservices at Twilio have evolved into "micromonoliths" as the services grow more complex and interconnected over time. It recommends establishing dependencies between services based on functional areas rather than technical boundaries to better reflect product and organizational structure. Using generated clients from API specifications and prioritizing splitting services can help reduce complexity as the system evolves. The document advocates reducing barriers to introducing new services so that the architecture remains flexible and adaptable.
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
Editor's Notes
- #2: 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
- #3: 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
- #4: 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)
- #5: 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
- #6: 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
- #7: 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
- #8: 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
- #9: GOAL: wrap it up, allow questions My email address is atiidumaa@twilio.com