3 ms·

So, some potential pitfalls: - The decision seems to be primarily a software architecture one, without much mention of all the other architects whose input wil

So, some potential pitfalls: - The decision seems to be primarily a software architecture one, without much mention of all the other architects whose input will shape how the finished product is run and supported. In a modern software development environment, all the other parts of the org should be consulted on greenfield work to "Shift Left" anything that may need to change down the pike. Design in a silo leads to ineffective products. - They're going from "hmm we need to upgrade from Python 2 to Python 3", to "we need to redesign everything in a new language with a radically different software architecture". This is definitely the second system effect. It's going to take years to make this thing reliable and sunset the old product. - They're porting over the logic? Even if this is actually the right move, wouldn't a clean-room implementation potentially give better outcomes? - Why are they continuing to use App Engine if the writing's on the wall for 2024?

batter 7y ago
Go + AppEngine is the most unstable combination i have ever seen. While we tried to deliver project during 1 year, it was almost fully rewritten couple times because of new Go or AppEngine API. Having NodeJS with far less problems. And AppEngine has huge price tag.
- pm90 7y ago
  GAE v2 let’s you use docker containers and ime it has been pretty stable and fantastic.
dangoor 7y ago
I don't disagree with your pitfalls, but I do think we're working to avoid them. To your first point, "The decision seems to be primarily a software architecture one...", this project has had involvement of the whole engineering team since the beginning. The whole org is on board with this change. It's definitely not happening in a silo. > This is definitely the second system effect. It's going to take years to make this thing reliable and sunset the old product. I hope not, but obviously we're not done yet, so I can't say how long it will end up taking to completely decommission the Python 2 app. What I can say is this: there are aspects to this project that are _simplifying_ our system and, for what's left moving from Python to Go, our intention is to port the business logic as close to a straight up port as we can get. > - They're porting over the logic? Even if this is actually the right move, wouldn't a clean-room implementation potentially give better outcomes? _That's_ second system effect, to me. We can't change everything and fix every problem now, so we're focusing on the changes that will help us move from Python to Go faster. > - Why are they continuing to use App Engine if the writing's on the wall for 2024? I don't think Google Cloud is disappearing in 2024, for one. Beyond that, again, we're not changing everything about our architecture. The way our data is stored is staying the same.
- scottrogowski 7y ago
  > The whole org is on board with this change. It's definitely not happening in a silo. Given the seemingly strong chorus of voices responding with cautionary tales about why you might want to rethink this plan, and the number of engineers in your organization, it seems more likely that you have some dissenting voices who have either been too scared to speak up or have already been shot down.
  - dangoor 7y ago
    What I meant by "the whole org is on board" isn't that there weren't other opinions. There have been multiple opinions on almost every decision we make (and we have an open process and document our decisions in a style very much like this one[1]). In the end, it's not about "shooting down" alternatives, since that's loaded language. It's about making what we think is the best choice we can with the information available to us. Even in this thread, there's a chorus of voices sounding caution based on their limited information of what our situation looks like, but there are others who see why we're doing this, based on the same limited information. We absolutely do know the risks of this project, which is why we're doing this as incrementally as possible. [1]: http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions http://thinkrelevance.com/blog/2011/11/15/documenting-archit...
Chloro 7y ago
App engine isn't going anywhere. Don't be so dramatic.

batter 7y ago

Go + AppEngine is the most unstable combination i have ever seen. While we tried to deliver project during 1 year, it was almost fully rewritten couple times because of new Go or AppEngine API. Having NodeJS with far less problems. And AppEngine has huge price tag.

pm90 7y ago
GAE v2 let’s you use docker containers and ime it has been pretty stable and fantastic.

dangoor 7y ago

I don't disagree with your pitfalls, but I do think we're working to avoid them. To your first point, "The decision seems to be primarily a software architecture one...", this project has had involvement of the whole engineering team since the beginning. The whole org is on board with this change. It's definitely not happening in a silo. > This is definitely the second system effect. It's going to take years to make this thing reliable and sunset the old product. I hope not, but obviously we're not done yet, so I can't say how long it will end up taking to completely decommission the Python 2 app. What I can say is this: there are aspects to this project that are _simplifying_ our system and, for what's left moving from Python to Go, our intention is to port the business logic as close to a straight up port as we can get. > - They're porting over the logic? Even if this is actually the right move, wouldn't a clean-room implementation potentially give better outcomes? _That's_ second system effect, to me. We can't change everything and fix every problem now, so we're focusing on the changes that will help us move from Python to Go faster. > - Why are they continuing to use App Engine if the writing's on the wall for 2024? I don't think Google Cloud is disappearing in 2024, for one. Beyond that, again, we're not changing everything about our architecture. The way our data is stored is staying the same.

scottrogowski 7y ago
> The whole org is on board with this change. It's definitely not happening in a silo. Given the seemingly strong chorus of voices responding with cautionary tales about why you might want to rethink this plan, and the number of engineers in your organization, it seems more likely that you have some dissenting voices who have either been too scared to speak up or have already been shot down.
- dangoor 7y ago
  What I meant by "the whole org is on board" isn't that there weren't other opinions. There have been multiple opinions on almost every decision we make (and we have an open process and document our decisions in a style very much like this one[1]). In the end, it's not about "shooting down" alternatives, since that's loaded language. It's about making what we think is the best choice we can with the information available to us. Even in this thread, there's a chorus of voices sounding caution based on their limited information of what our situation looks like, but there are others who see why we're doing this, based on the same limited information. We absolutely do know the risks of this project, which is why we're doing this as incrementally as possible. [1]: http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions http://thinkrelevance.com/blog/2011/11/15/documenting-archit...

Chloro 7y ago

App engine isn't going anywhere. Don't be so dramatic.