A lot of companies are moving from monolithic architectures to microservices. While there are many benefits to microservice architecture such as decoupling development and deploy cycles between different parts of the team, there is a lot of overhead for each additional microservice you introduce. There is this balancing act around the right granularity to make microservices and when to use libraries vs services. This desire for an in-between ground is what is fueling the function as a service movement. Drawing from Transposit’s approach to building a compositional layer where this glue code between services can live, this talk will discuss both the operational necessity for such an intermediary and how having one can speed up your team’s development and deploy cycles.

1. 1
A Future History of the API
Composition Platform
Tina Huang
CTO & Co-founder, Transposit
Previously at Twitter, Google, and Apple

2. 2
APIs are eating
the world

3. API-first development
3

4. A forest of APIs

5. Square pegs, round
holes, special snowflakes

6. One pagination
mechanism to rule
them all
6

7. Complexity in
interactions
7

8. API composition
8

9. Sharing
9

10. 10
What now?

11. Libraries and modules
11

12. Microservices
12

13. Serverless
13

14. FaaS (Functions as a Service)
14

15. 15
Let the platform do
the magic

16. FaaS for API Composition
16

17. Intent, not mechanism
17

18. 18
Here’s what you can do now
• Adopt internal standards about how you create APIs (1 pagination method please!!)
• Adopt open standards around API definitions e.g. OpenAPI
• FaaS is a thing
• Your public cloud vendor has a version for you to start to experiment with
• You have a cacophony of options on-premises
• Your APIs are products; manage them like you manage products. Think about how your
users are going to interact with your APIs

19. 19
API lifecycle

20. 20
Questions?
Tina Huang
tina@transposit.com
Artwork courtesy of Freepik