Taro Logo

Advice on AWS Migration?

Profile picture
Mid-Level Software Engineer [RE2] at Taro Community6 months ago
  • Company is doing an AWS migration (with lambdas). We're moving away from old IBM architecture.
    • Goal is to move away from SOAP service to build scalable REST API.
  • I have limited working experience with AWS but never touched Terraform or have needed to do any migration work at all.
  • We'll be building out lambdas and transferring traffic over to our new service
  • Team is also new to NodeJS (with the exception of some new folks i.e. me and some other people)

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

  • General recommendations for succeeding in this ambiguous domain?

  • Resource recommendations?

Thinking of skimming AWS docs / AWS course to quickly learn basics but planning on spending most of my time on implementing lambdas with mock data -- goal is to share POCs with team and iterate on feedback before sharing our new service with stakeholders.



  • 3
    Profile picture
    Team Lead (people manager) at Mistplay
    6 months ago

    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!

  • 2
    Profile picture
    Startup Engineer
    6 months ago

    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.

  • 5
    Profile picture
    Tech Lead @ Robinhood, Meta, Course Hero
    6 months ago

    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: