Hello-world Solutions
20 Nov 2021Goal
- To review our helloworld microservice against the tenets of microservice architecture, and see if we are at a better place from where we began.
Discussion
Here is a quick review of where our little microservice stands now, in terms of the “microservician” utopia:
| Tenet | State | Observation |
|---|---|---|
| Loosely coupled | Neutral | N/A? We just have one service. Nothing to couple yet. We will get there :) |
| Cohesive | Neutral | Not a lot of cohesion to discuss with helloworld. So, same as above. |
| Deployable | Better | By using Docker-based containerization and by managing and orchestrating container deployments via Kubernetes, we have improved the deployability of our microservice. By using the canary release feature of Ambassador, we have improved fine-grained control over our deployments. |
| Reliable | Better | Due to the orchestrated and scaled environment, individual node failures no longer bring down the entire service, and hence we have improved the reliability and availability of our microservice. |
| Scalable | Better | Since Kubernetes can quickly scale up and down as necessary, we have improved the scalability of our microservice and elasticity of our production environment. |
| Maintainable | Better | Using Kubernetes, patches to code or any dependencies can be applied without bringing down the pods, thereby reducing the need for maintenance windows and increasing the maintainability of the overall architecture. |
| Observable | Better | Using Ambassador, Prometheus and Grafana, we now have ways to capture, monitor and visualize the various metrics that are relevant in understanding the health and performance of our infrastructure. |
| Evolvable | Beginnings | While our code is too simple to be discussing evolvability, we have attempted to version our APIs, thereby solving a piece of the puzzle for an evolvable architecture. |
Summary
We have achieved a lot with just a simple helloworld microservice. We also realize that there is so much untapped potential with the abilities of software we deployed and configured. For example, we have so much more to get from our API gateway. We need to explore rate limiting, authentication, logging, tracing etc. We also need to push the boundaries of the infrastructure and see how it performs at load. We need to try out various load balancing algorithms. We have barely scratched the surface of Kubernetes.
But, we will forcefully take a break from this line of exploration here. After all, these tools start warming up only with interplaying services, where we deal with high coupling, complex computations, big data, concurrency etc. We need complexity. We need code. We need data. So, we bid adieu to our helloworld service here, as well as to Part 1. We will come back with a new area to explore in the next part. Onward we shall go!
