Structuring backend (REST API) into microservices with Kubernetes (or serverless)

8/3/2018

I'd like to design my next project in a microservices-based architecture rather than as a monolith. Are microservices generally defined as a set of endpoints that compromise a service (i.e. common dependencies, functionality, etc.) or would each endpoint be its own service?

I've used Serverless Framework before, which defines each endpoint with its dependencies and packages it into a Lambda/FaaS. In Kubernetes is this analogous to each endpoint living in its own pod?

I'm having some trouble thinking about the ideal way to design a new project from the ground up that can make use of autoscaling, microservices, and pay-for-usage, and haven't found much information around it.

Any thoughts/resources on this subject?

-- rhlsthrm
amazon-web-services
kubernetes
serverless

1 Answer

8/3/2018

I would recommend you to start from scaling perspective. Separate apps that should be scaled from apps that shouldn't. That would be Pods.

Define the connection between apps taking into account fault tolerance and load balancing. Define the autodiscovery strategy. That's what Services is used for.

Think about how you expose your apps to the outside world. That's what Ingress is for.

Think about how you restart and update your apps. That's what Deployments do.

Think about cluster security. This is where Network policies come to play. Project Calico provides more flexible solution.

Think about the availability of the whole cluster. Here come the Kubernetes HA clusters

In special cases you may need to use DaemonSets, Jobs, CronJobs and StatefulSets.

If you decide to go deeper, check out other articles in the Kubernetes concepts section of the official site.

-- VAS
Source: StackOverflow