Advice on AWS Migration?

The idea of building some POC’s yourself to get the team started with examples and a bunch of learnings - and then iterating from there - sounds good.

From my experience sharing new technology with the team this is a great strategy. Reading docs and getting certifications only gets you so far. Having a working example, plus all the knowledge you have from building that example yourself will be very useful.

I can’t speak to this domain specifically but general advice is to keep the new components of the project simple. I think the temptation when building something new is that it seems complicated so the system ends up being complicated. But iterating and collaborating with the team until you have the project broken down into individual simple pieces and steps would be great.

Would love to hear specific answers from domain experts on this question!

Any recommendations on how to best succeed given the current context?

• General recommendations for succeeding in this ambiguous domain?

• Resource recommendations?

Read the docs! Knowing what's available and how the developers want you to use their API is part of familiarizing yourself with a new tech stack.

For resources, I used A Cloud Guru and their playground to learn about the services AWS offers. I would just think of AWS as a set of prefabbed microservices that easily operate together. The sdk encourages Code as Infrastructure so I would lean heavily into learning how to architect these services and the right way to write CloudFormation stacks.

I have worked on Node.js, but not AWS. Regardless, there isn't anything specific about those technologies that prevents the following migration best practices from being true:

• Be able to revert back - Working at Big Tech has taught me to never underestimate the amount of stuff legacy code is doing. It's easy to look at it and just see spaghetti, but sometimes the jank is handling a mountain of edge cases you didn't even realize existed. If this happens and your cut-over to REST explodes, you should have a switch that can put all traffic back onto the legacy SOAP services while you figure out why the new endpoints are busted.
• A/B test and have good analytics in general - Understand the current performance of your legacy API suite, so you have a benchmark to ship (or not ship) the new REST APIs. Remember that at the end of the day, the end-user doesn't care how your code works underneath. It doesn't matter if the new code is more "modern": If it's less reliable and less performant, you just shouldn't ship it. For ideas on what to measure, check out this discussion: "How can I demonstrate the impact of migration projects in a platform team?"
• Migrate incrementally if possible - Big migrations are always 2-10x harder than engineers and engineering managers think. To minimize risk, try to add new endpoints with the updated architecture to build the muscle and understand the quality. In parallel, you can fork the old endpoints to create new versions with that switch I mentioned before.

General recommendations for succeeding in this ambiguous domain?

Ask a lot of questions, don't be afraid to build and break stuff (in staging of course, not prod), and it's better to ship something janky and iterate on it than to try and ship the perfect thing.

When it comes to learning new technology, I recommend these:

• "What is the effective way to understand new repository in order to make the required changes in that repo?"
• "How do I make software less overwhelming?"
• "How can I write great code faster?"