DEV Community

Pacharapol Withayasakpunt
Pacharapol Withayasakpunt

Posted on

A question about transforming a monolith to microservices

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?

Top comments (9)

Collapse
 
absinthetized profile image
Matteo Nunziati • Edited

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.

Collapse
 
patarapolw profile image
Pacharapol Withayasakpunt

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

Collapse
 
absinthetized profile image
Matteo Nunziati

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?!)

Collapse
 
louy2 profile image
Yufan Lou

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.

Collapse
 
rolfstreefkerk profile image
Rolf Streefkerk

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.

Collapse
 
patarapolw profile image
Pacharapol Withayasakpunt • Edited

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.

Collapse
 
rolfstreefkerk profile image
Rolf Streefkerk • Edited

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
Collapse
 
patarapolw profile image
Pacharapol Withayasakpunt

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.

Collapse
 
rolfstreefkerk profile image
Rolf Streefkerk

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