4 ms·

I blogged about this[1] as we were starting the project. The short story is that moving from App Engine 1st Generation+Python 2 to App Engine 2nd Generation+Pyt

I blogged about this[1] as we were starting the project. The short story is that moving from App Engine 1st Generation+Python 2 to App Engine 2nd Generation+Python 3 would have _also_ been a ton of work, but would have given us fewer benefits out the other end. We reduced risk in the project by making it very incremental[2]. All of this Go code has been incrementally put in front of users without anyone really noticing. As a non-profit, we absolutely did need to justify it to our senior leadership and board. They've been super supportive because they know exactly what we're dealing with and how this benefits us for the long term. [1]: https://blog.khanacademy.org/go-services-one-goliath-project/ https://blog.khanacademy.org/go-services-one-goliath-project... [2]: https://blog.khanacademy.org/incremental-rewrites-with-graphql/ https://blog.khanacademy.org/incremental-rewrites-with-graph...

mwcampbell 5y ago
I wonder if the Khan Academy engineering team has come to have any regrets about the change from a monolith to multiple services (micro or otherwise). Do you feel that the move away from a monolith was forced by the transition off of Python 2, and would have been best avoided otherwise? Do you miss the simplicity of an integrated application where you don't have to deal with the added complexity and failure modes of multiple communicating services? To put my cards on the table, I feel that most web applications are best implemented as a monolith with server-side rendering, not a back-end API (e.g. REST or GraphQL) plus front-end code consuming that API. My thinking on this is largely influenced by DHH's promotion of the "majestic monolith" pattern, e.g. https://m.signalvnoise.com/integrated-systems-for-integrated-programmers/ https://m.signalvnoise.com/integrated-systems-for-integrated...
- dangoor 5y ago
  It is more complex, to be sure. I actually think that we're not yet getting all of the benefits that we'll ultimately get from services. For example, we have one deploy queue still, so we'll likely benefit when teams can deploy even more quickly because they're not waiting on other teams. Multiple services also makes it so that a deploy of one service gone awry is less likely to cause problems on the whole site. I also think that the maintenance will be better over time. It'll be easier to swap out the guts of an individual service. But, we haven't gotten to that yet. We _have_ already gotten benefits from certain things being in separate services. The best example of this is with our "content" service which, as you might guess, provides content data and metadata to the rest of the services. Since this is a separate service, it's able to store a whole bunch of content directly in instance memory, so it can respond to queries very quickly. This part didn't work as well in the monolith. I don't think I'd argue for services in general for a smaller team (Monolith First[1]), but I do think that splitting some bits out that have very different operational characteristics (different traffic patterns or uptime needs) can be worth it, even for smaller teams. [1]: https://www.martinfowler.com/bliki/MonolithFirst.html https://www.martinfowler.com/bliki/MonolithFirst.html

mwcampbell 5y ago

I wonder if the Khan Academy engineering team has come to have any regrets about the change from a monolith to multiple services (micro or otherwise). Do you feel that the move away from a monolith was forced by the transition off of Python 2, and would have been best avoided otherwise? Do you miss the simplicity of an integrated application where you don't have to deal with the added complexity and failure modes of multiple communicating services? To put my cards on the table, I feel that most web applications are best implemented as a monolith with server-side rendering, not a back-end API (e.g. REST or GraphQL) plus front-end code consuming that API. My thinking on this is largely influenced by DHH's promotion of the "majestic monolith" pattern, e.g. https://m.signalvnoise.com/integrated-systems-for-integrated-programmers/ https://m.signalvnoise.com/integrated-systems-for-integrated...

dangoor 5y ago
It is more complex, to be sure. I actually think that we're not yet getting all of the benefits that we'll ultimately get from services. For example, we have one deploy queue still, so we'll likely benefit when teams can deploy even more quickly because they're not waiting on other teams. Multiple services also makes it so that a deploy of one service gone awry is less likely to cause problems on the whole site. I also think that the maintenance will be better over time. It'll be easier to swap out the guts of an individual service. But, we haven't gotten to that yet. We _have_ already gotten benefits from certain things being in separate services. The best example of this is with our "content" service which, as you might guess, provides content data and metadata to the rest of the services. Since this is a separate service, it's able to store a whole bunch of content directly in instance memory, so it can respond to queries very quickly. This part didn't work as well in the monolith. I don't think I'd argue for services in general for a smaller team (Monolith First[1]), but I do think that splitting some bits out that have very different operational characteristics (different traffic patterns or uptime needs) can be worth it, even for smaller teams. [1]: https://www.martinfowler.com/bliki/MonolithFirst.html https://www.martinfowler.com/bliki/MonolithFirst.html