Splitting your monolithic application into microservices
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
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.