A question about transforming a monolith to microservices

patarapolw profile image Pacharapol Withayasakpunt ・1 min read

Looking to transform a monolith to static hosting with microservices (with database connection). I was asking this on Google Cloud Support, actually.

  • Is it a good idea?
  • Where to host static part? Does it have to be Google Cloud Storage?
  • Cloud SQL vs MongoDB Atlas (vs MongoDB Stitch)?
  • How to protect the API endpoints? I heard someone said API Gateway...

Truth be told, Netlify lambda threw a little error on Webpacking a MongoDB connection (IIRC, it was about encrypting as well). Should I attempt Netlify again? What about Vercel? Not to mention the database connection alive time.

I am perfectly happy with Google Cloud Run, actually (fully-managed Docker hosting platform); but is it too monolithic?


markdown guide

How big is your app? and your team? the concept of microservices is related to decoupling the activity of very big teams working on very big apps... Unless you have 5+ developers, microservices-vs-monolith make no sense at all IMHO.

Also SQL vs NoSQL is not a microservice thing, is a design thing related on how you need to manage your data.


Qovery guy also said so. Just monolith first, until it scales.


Yes, because you have to remember that more services require more boilerplate, more deploying time, more of non-core activity, therefore: either you automate every single bit to the extreme, or you are open to pay a lot of time to non-core as this saves time in development management (e.g: how the fox can I manage this new piece of functionality while not crashing everything around?! how can I better manage the scrum/agile/anything approach for a project such big?!)


warmup plays a role in request latency sure, but you make it sound much worse than it really is. If functions get called regularly the under lying containers are not getting decommissioned as readily. Only once every so often that will happen.


There's nothing "too monolithic" in general. I have heard that StackOverflow remains largely monolithic. Benchmark your application and test for yourself how any change, including change in architecture, affects the performance, the cost, and the user experience. If you fear function warm-up time, benchmark it.


GCR seems to support Cloud SQL connection as well. Not that I have tried it.

Have always been using MongoDB Atlas, but the lack of automatic backup (unless I pay at least about 20 USD / mo) makes me want to move away from it. Also Google Cloud credits won't cover for MongoDB Atlas.

Function warm-up time is what I fear too.


you can replace these with the google cloud variants if you wish, I know AWS reasonably well. Basically you use these components:

  • Static hosting: S3 object storage, web enabled, optionally a CDN (CloudFront)
  • API: API Gateway, API protection, rate limiting, and authentication with AWS Cognito
  • Compute: AWS Lambda, FAAS with Node.js runtime or Python
  • Database: DynamoDB, NoSQL schemaless

I still prefer to set a schema from the outset if I can.

It would also be nice if the schema is UNBREAKABLE, unlike using ODM on top NoSQL.


if you like strict schema's I suggest SQL based databases.

If you want a Serverless variant, have a look at AWS Aurora Serverless for both MySQL and Postgres