Topics Discussed:
- What is and Why microservices?
- Advantages of Microservices
- How does the inter connection works ?
- How can we Secure the inter connections?
- Best practices in Microservices
- Example Architecture
Introduction
> During Initial days application migrated without any planning to k8s.
> This resulted in heavy sized containers and images. It took too much time to download or upload a container in case of any recovery operations or issues.
> Thinking about modularizing the applications comes with devops practices.
How to implement microservice architecture
> Need to understand data flow first to implement microservices in an application.
> An application microservice’s first step is api calls and it will be the base of app communications.
> Api can develop in any coding language and can use any method to communicate like POST etc..
> We can develop applications using loosely coupled architecture so that dependency can be negligible for service to each other.
> To implement the communication endpoint with each service we can use environmental variables with the applications.
> In kubernetes this can be achieved using configmaps.
> Advantage of configmap is, there is no need to modify the application in terms of infra changes.
Advantages of microservice
1. Since the application size got reduced we can also reduce the timeline of development using this architecture.
2. So the entire application will not go down, instead a feature can be down or not available.
We will avoid GET requests and mostly use POST with a token header to use with interconnection of applications. We can take the token from secrets or vault or keycloak or OPAM etc. Authentication needs to ensure the security level of api requests too to reduce attack faces
Disadvantages:
1. Interconnectivity needs to be secured using token headers.
2. We should make sure the frontend web server should send traffic only to the backend used for that specific server pod only.
3. We need to implement service mesh as part of interconnectivity security.
Servicemesh:
> Tags or labels can be used for servicemesh implementations to ease the communication mapping for the pods.
Servicemesh and Istio implementation.
Istio is a software defined networking control implementation mechanism. We use istio to implement such kinds of networking rules. We can use it for end to end network debugging. Canary deployments and blue green can be achieved using istio easily. La bels and selectors only do round robin . But istio can control traffic percentages to pods using istio. Mutual tls implementation can be achieved using istio.
Authentication
> One of the main problems we used to face in application development is too much level of authentication.
> Suppose the microservices, after first level authentication the call will transfer to the next layer. There also needs authentication to confirm privileges and rights and user authenticity. So it will lead to RBAC integration with applications and we can implement this as a separate component.
> Try to keep the authentication module separate.
> There is no need for a separate authentication at the network level, so once the task for a session is done, it can be expired.
> All decisions about authentication mechanisms and stages depend on the architecture only.
How can I make an image so light?
Use a double build. So from one build to the next we only need to transfer artifacts.
Cluster sizing w.r.to application
> Source location needs to be transferred with the request to get the answer for the request to its origin or the requester.
> It doesn’t matter how many requests there, pods will scale up and scale down . We only need to ensure that the cluster has enough resources there.
> We only need to implement microservice at the place where the bottleneck, rest can be monolith, and thus we can reduce cost using microservice architecture.
CNI selection
> It depends on the purpose you want to implement in the cluster.
> If you want network policy you can go for calico.
Web and DB design best practice.
We have similar services and do we need separate backend for each?
> If each service needs to serve the same data then you need a single db.
> DB is always better to be configured as statefulset.
> For shopping cart kind of apps we can have frequent using service and some other service not using frequently. So we can use nosql db for frequently accessing service and sql db for remaining services like that.
Kafka in azure
> Can use eventhub in azure with a kafka compliant endpoint.
> Kafka is not an exact solution for db or storage. Its a streaming solution and mainly using for that purpose.
> If we have a retention period, we can run statefulset and headless service method of implementation. But its hard to manage.
> If we have enough budget, we can use managed kafka solutions available in the market.
> Kafka is working as all other distributed solutions. We can implement it in multi region, multi zone or hybrid etc…
> It has a leader, follower concept. Its using zookeepers to save and manage that leader and follower state.
