Key Takeaways
- You can migrate your service virtualization with OpenSource tools to cut tooling costs but might need to supplement with other commercial offerings to cover missing protocol support, i.e. IBM MQ.
- Decoupling the teams' schedules and allowing them to migrate at their chosen pace has proven to be the most effective.
- Use an internal mailing list and brown bag lunches to share knowledge about migration, best practices, common mistakes, and other learnings.
- Manage the lagging cohort — allow teams to stay with an existing tool or postpone if the budget allows
- Look for tools compatible with an infrastructure-as-code approach with ephemeral containers if that is what you already use.
- Sharing the configuration files and simulators between teams can save you time.
Introduction
I have worked closely with three teams at a large retail bank as a vendor representative, helping them migrate from a commercial service virtualization tool to OpenSource WireMock and another less costly commercial tool. I have also been briefed on how other teams at the bank have migrated to tools like Mountebank.
Most virtual services were migrated to the OpenSource tools, but the teams had to supplement with commercial offerings. Selected groups migrated away from a monolithic-like centralized service virtualization approach to the ephemeral distributed microservice-like API simulation approach.