How to think about microservices?

Question

I am in the learning process of converting my monolithic GAE app into a Microservices Architecture.

I understand that the app is separated into services that can communicate with each other. Different categories of requests are handled by different services as designated by the dispatch.yaml file.

How do we determine what to make into a service? Consider an online job board website which has the following functionalities:

• There are two user roles: JobSeeker and Company
• Companies can post a Job entity
• Job Seekers can create a JobApplication entity (that corresponds with a Job)
• Both user roles can have to be authenticated
• Companies manage their own CompanyProfile
• JobSeekers manage their own list of JobApplications and their JobProfiles

What is the guiding thinking process that goes into separating our app into a microservices?

Answer 1

Some of the places that microservices are advantegeous over monolithic application are:

• When you want different release cycles for different parts of your application.
• When one component is used by numerous different upstream components (e.g. a shared authentication system.)
• When you want to isolate failures (e.g. so a upstream component can gracefully degrade if a downstream component is down.)
• When you want to limit the scope of data availability (e.g. keeping encryption keys to the smallest possible surface)
• When you want to minimize the stateful parts of your application (e.g. so you can have a stateless frontend that scales easily and a stateful backend that you scale by sharding).

In other words: split up into microservices where it will actually be useful to you. Merely splitting up your application for the sake of it is going to make your life more complex than necessary.