Service Completeness on kubernetes

Service Completeness on kubernetes

Note: This isn't a verbose blog post covering all aspects. This is more of a "I want to confirm what I already know" kind.

When migrating microservice to kubernetes, it's essential to see if the application is completely migrated.

How to mark it as completed?

Usually, application life stages span in following stages:

  1. Development: Covers version control, collaboration between developers, workflow of how the commits are pushed, etc.

  2. Testing: Once the commits are made, ci pipeline builds a docker image.
    Testing covers independent unit testing of the application and validates itself with all the client contracts. Maintains previous versions as is, and informs of any breaking changes to stakeholders.

  3. Deployment: Once the testing is complete, cd pipeline uploads the docker image to might have been uploaded in earlier stage, depending on your approach. Once the new version of image is uploaded, update your kubernetes yaml files with new version number. Then do kubectl deploy or any other workflow you may have. We use flux.

  4. Monitoring: Application has to be monitored. Check your application overview dashboard, alerts setup, resource constraints, autoscaling, health of the service, logs reporting too many errors, 99 percentile, latency, SLA, SLO, connections to external services, etc.

  5. Logs: Make sure you've a dashboard to see if logs are appearing and if they're structured in desired way.

  6. Feedback: Once the application is deployed and running in production, make sure you've all the feedback associated are at a central place. Feedback differs from monitoring in a sense that monitoring tells you if it's working as you expected, feedback tells you if it's to be improved.

If all the above are marked as complete, you may say your application is completely migrated to kubernetes.