Splitting your monolithic application into microservices

Notes

Splitting an application into a collection of coupled services can help simplify your projects and clarify contributor responsibilities. After awhile, you may come to realize that your monolith codebase is getting too big to handle. This a common problem software projects come up against, even the most successful microservice systems, breaking up as they grow. If your app has become a giant, Platform.sh's configuration makes breaking it up into separate application containers very straightforward. You can move your existing application to a subdirectory, including its .platform.app.yaml file. You can then move a new application, such as your API backend to its own subdirectory, one that will contain its own .platform.app.yaml file inside of it. Here, we’re defining the backend application to use the Node.js 10 runtime. It installs its dependencies during the build hook with npm install and contains a single relationship to a RabbitMQ service. The app’s start command uses PM2 to run index.js, and inside that file we can define a simple web server that listens on the Platform.sh-defined port to serve some HTML. Since your services will be shared between each application container, everything in the .platform hidden configuration subdirectory will remain in the project root. You can optionally add additional services to your services.yaml file to help coordinate how your applications talk to each other - such as adding RabbitMQ to allow them to communicate asynchronously. In your new microservice's .platform.app.yaml file, you can also configure the application to spawn worker containers with their own run configuration. Push the changes, and Platform.sh will orchestrate the newly configured cluster automatically. In your management console you will be able to see that your Service Graph has been updated, now with two application containers. When you're satisfied with your new infrastructure, merge to master and see the changes in production from that point on. There is no requirement that application containers use the same runtime, so feel free to mix and match our supported languages to fit your needs.