loading...

Is it okay if my app is not microservices-based?

simpleauthority profile image Jacob Andersen ・2 min read

I have a bad habit of throwing myself into analysis paralysis over issues that I shouldn't be thinking so hard about.

I also tend to hop on bandwagons and then get lost in the technobabble.

To be clear, this post is not so much seeking to give advice, but to ask:

Is it okay if my app is not microservices-based? At least, at the start?

Do you recommend any articles I can read about the topic and when to split the app into microservices?

I am developing an application that is highly ambitious -- it aims to teach languages, but also to be a social platform for those learning the languages. In its future, it aims to be a dating platform and also offer e-commerce services.

For now, we just want to get off the ground.

I decided to go with Spring Boot and with that I also decided that to go with microservices from the ground up.

Now, in development, I have to run 6 apps just to test a few routes and it's quickly becoming unmaintainable and I'm certain there are people on the verge of imploding with Cringe(TM) as they read that.

I'm coming to the understanding that for an app to be properly split into microservices, each microservice actually needs to be able to run on its own and stand alone. If for example one goes down, that would not affect the entire application as a whole.

In my case, if one goes down, the entire thing goes belly up. So really, what I'm doing is running a complex monolith...with separate code-bases. Would you agree?

I'm generally just looking for some guidance here. I'm seriously considering going with a single Spring Boot (monolith) project to seriously simplify the project, my life, my productivity, and my stress levels.

Is that okay?

Posted on Mar 20 by:

simpleauthority profile

Jacob Andersen

@simpleauthority

I'm a 22-year-old professional full-stack developer. I'm currently working on a startup to teach Tagalog and Bisaya.

Discussion

markdown guide
 

"'I'm seriously considering going with a single Spring Boot (monolith) project to seriously simplify the project, my life, my productivity, and my stress levels." - these are all very good reasons for not building microservices.

The fact that your app is unproven in the marketplace (as you said) is another very good reason not to build microservices.

If the app becomes highly successful and needs to evolve and possibly runs into scalability and maintenance issues, you might regret not having started with microservices... but this is a good problem to have :-)

 

If the app becomes highly successful and needs to evolve and possibly runs into scalability and maintenance issues, you might regret not having started with microservices...

I'll be honest, this makes me anxious. That is, having built the application to a working state as a monolith (or a few monoliths, in the case of separating the social/learning/dating/e-commerce aspects while still keeping these fairly monolithic) and then needing to figure out a way to convert them to microservices to scale out.

Perhaps by then, it won't be a job for just one developer (me).

I really appreciate your reply. Thanks!

 

It should make you anxious (that means you understand the problem well), so keep that future V2 of the architecture in mind when you are designing your V1 monolith and make the various capabilities (e.g., social, learning, dating, e-comm) very cleanly separated within the codebase and - most importantly - in the database.

 

It's absolutely fine, even good! If a new feature really needs to be decoupled, you will know by then because at that time you will have a much better grasp of the codebase, requirements, complexities, etc. :)