Project Templates, Design Patterns and Moving from Node.js to Java
You start with a single engineering project, and it quickly expands with changing business requirements. After a period of rapid company and team growth, the project becomes an extensive monolith application that’s being iterated on by multiple engineering teams. This situation causes complications with deployment, managing releases, merge conflicts and general developer productivity. As a result, you decide to split the application into microservices, but that’s when the real problems start. How do you build and scale a microservices architecture along with your engineering team?
Without some way to standardize development, you now have several engineering teams building out features on their part of the platform, all using a development life cycle that best fits their team. The microservices start to look drastically different from each other with varying degrees of testability.
A lack of consistency in the codebase raises other challenges. For example, a developer onboarding process is now required to suit your team's development process. It also creates difficulties in cross-team collaboration. Production issues are harder to debug if developers cannot intuitively understand another team's service. When an issue can only be effectively diagnosed by the team that owns the service, the production on-call must now quickly identify which layer of the platform is exhibiting issues and page the corresponding team.
At Ripple, we had this type of engineering growth from an application to a microservices platform while parallelly growing the engineering team. At the same time, we were moving RippleNet Engineering from Node.js to Java while maintaining release velocity. This move to Java enabled us to implement enterprise design patterns easily. And perhaps more importantly, our on-premise (on-prem) customers are more likely to have Java expertise and can help manage on-prem deployment.
To help us manage growth, release velocity and a change in the programming language, we used project templates including Maven Archetype to get our developers up and running quickly with the design patterns, libraries and tools they need to write high-quality code.
We use Maven as the primary build tool so Archetype was a natural choice. The project archetype laid out the foundation for our new Java projects, and allowed developers to focus on implementing features.
In Part 2 of Scaling Code, Scaling Teams, we will discuss specifics on our principle design patterns, writing testable code and consistent continuous integration (CI) and release pipelines.
If you’re interested in joining Ripple’s engineering team, we’re hiring!