Welcome to part two of a series on Here is a diagram of a rearchitecturing of the existing php monolith at http://ninjawars.net (currently using an EC2 server behind an application load balancer and RDS database), into microservices (using CloudFront, ApiGateway, Lambdas, RDS & DynamoDB, and still EC2 for the PHP).
Here is an architecture diagram of how various parts of a monolithic php application on an EC2 server, behind an application load balancer and with an RDS database) could be transformed into a microservices (using CloudFront, ApiGateway, Lambdas, [still] RDS, and -without- totally rearchitecting the EC2 server core (in the interest of time)
So above we see one of the largest problems with servers and web servers is: What if you're not starting from scratch? What if you, in fact, don't have serverless or a modern architecture foundation because you have a legacy app?
Wrangling the legacy core
With a legacy app, it becomes much harder to say "ah, just use serverless" or "just use AWS Amplify!" because the whole of the existing app was started many years ago and works with a different paradigm, a monolith.
The above diagram details just that problem, an app written in php, for which the paradigm was originally serverFULL. Or rather, written before serverless became mainstream. Since usually in such cases we don't want to rewrite most of the functionality, we have to find a way to create a hybrid solution.
Make your monolith your core
Here we see a bit of detail view of the monolith (read both UI and behavior mixed together) taking a central position in orange within new architecture. The most time consuming aspect of things is often the coded behavior. We don't want to rewrite everything at once; often a disastrous mistake in hindsight.
Split out low hanging fruit
Separated database
One of the easier moves to make is to split out the data from the server logic:
simply because relational databases often are segregated within their separate app already (postgresql in this case, or mysql, mariadb). Now, the cost of RDS is not low, likely because any 10 minute apart snapshot of a database is going to be different! So backups are crucial and AWS having a robust backup system increases the cost. If an obstacle to splitting out the database to RDS is cost, it is possible to simply host the database server on it's own separated EC2 instanced. I do recommend starting with RDS and auditing cost as you go.
Separate the Javascript API
If you are working on the web, you may already need some API separation, as this system did, and the api becomes another good target to separate out of the monolith, as I have here:
While it may be complicated to create a full fledged api, getting to an iterable point is desirable.
In the first phase, look for:
- public data that does not require authentication.
- settings that save for viewers who are not logged in
- environmental data that are not dependent on users
- products that are always publically viewable
Hold off on:
- data that users only have after login
- administrator access (again, requiring admins to log in)
Why? Because setting up distributed authentication is the next step, but Auth is not an easy piece to architect. It requires knowing the current system, what sdks are available, and is not easy.
A few more pieces of low hanging fruit
Before we address Auth, let's list a few more pieces of low hanging fruit:
- Email (again, often already separated out to a different service) -> consider splitting off to SES instead of rolling your own
- Blog post data (may require auth, but could be a seed area to get a serverless portion running)
- Chat data (again, auth required) -> chat systems are often good hello world apps, so can be used to get a serverless foothold to build out from
Onwards to Auth
In the next part I will talk about one of the major obstacles, Auth...
Top comments (0)