A light. A beacon of hope. For months our team searched for this beacon. This treasure. Together, exploring the depths of the unknown, we ventured into the dark and treacherous sea of Kubernetes armed only with our curiosity and imbued with a passion to make due on the promise of a better world — one in which the mysteries of Kubernetes no longer lived in the dark. One in which we could bring this magic to the light with the power of Visualization. We bring this treasure from behind the perilous gates of the almighty AWS empire — to be celebrated and rejoiced among our people in the land of OpenFaas. Our journey has been long, and it is far from over. Though we have served our purpose, we know that this mission is not only our own. We have just returned home to a heroes welcome, but our focus now is on providing our future disciples with the roadmap they need to continue this adventure. This* is that sacred roadmap. If you are reading this, perhaps you and your fellow voyagers can finish what our great ancestors started.
If you can’t tell by now, VaaS is more than a product. It’s a story. A story not of individuals, but of a group who have worked together in an attempt to revolutionize Kubernetes visualization for the OpenFaaS community. Admittedly, there is a long way to go before VaaS is ready to be consumed by real-world developers, but nonetheless, our contributions have VaaStly improved not only the product, but the developer experience for future iterators.
Our first decision as a group was to migrate VaaS to use Vite middleware, allowing us to to convert our application into Server Side Rendering (SSR). This not only improved the efficiency of our build process, but made the entire application faster and more responsive. Of course, this migration introduced several additional complexities as well. For instance, without being able to rely on client-side rendering, we were unable to use local storage to store and pass data between front-end components. VaaS, as we inherited it, was using local storage to store JWTs for authentication purposes, and we were therefore tasked with reconfiguring our backend to store JWTs in cookies instead. Now, JWTs are responsible for authenticating users and preserving the status of their login for specified intervals of time before resetting upon each of their subsequent visits.
One of the biggest reasons why accomplishing the migration to SSR was so important was because of the rendering burden being incurred by all of the visual tools we were looking to provide within the application. Prior to our iteration, the few existing graphs provided were monitoring user clusters inefficiently and statically. With our SSR in place, we knew that we could expand our application to provide more dynamic, robust visualization tools, but before we began adding any new features, we turned our focus to one last roadblock.
Throughout our early experiences and in past iteration teams, the hassle of monitoring locally hosted minikube clusters was a detriment that slowed any potential product improvements. Fascinating as it was, working on VaaS for past developers was often a case of “it works on my machine but not yours” (VaaSian ancestor). With this in mind, we knew early on that we could not make any true progress forward until we figured out a way to lift this burden and streamline the VaaS development process. To do so, we began a quest into the world of Cloud Computing, and before long were able to successfully deploy a cluster on the Google Kubernetes Engine and import its services within our application. For the first time in their illustrious history, VaaS engineers could link their local machines to the same, multi-node cluster, finally freed from the limits of minikube. Like caterpillars to butterflies, we were finally able to spread our new wings, and begin to explore the unlimited potential that VaaS could bring — a light that could illuminate the dark, unknown world of Kubernetes — Vision as a Service.
At this stage, we were now equipped with both a legitimate, accessible cluster, and a SSR foundation to support visualization tools to measure it. Now we turned our focus to deciding which tools we wanted to incorporate.
Firstly, we wanted to make our imported Grafana dashboards more robust and dynamic. We accomplished this by implementing the Kube-Prometheus Stack Helm Chart in our cluster, converting the prometheus-grafana service to a LoadBalancer, and importing each provided dashboard into our application as iframes. Unlike the few Grafana panels that were formerly available for users, they now have access to 15 complete, robust dashboards that now render visualizations immediately and dynamically (with the capacity to import even more). In order to make all these dashboards more digestible for users, we have gone through the work of sorting and categorizing them in terms of computing resources, networking, core resources, isolated workloads, overview metrics, custom dashboards, and OpenFaaS metrics.
Additionally, we used the KubeView Helm Chart to revamp the existing Kubernetes visualizer within our application. Unlike the previous visualizer, our new visualizer gives users key insights into the architecture and real-time status of their cluster. With the dynamic color-coding of nodes, users can now use the VaaS visualizer to identify if any deployment, service, or pod is healthy, down, or in the process of being configured. Additionally, they can investigate any individual component further and even look into their corresponding YAML file to check logs or perform any other debugging procedure. After diagnosing the cause of problems when they arise, users can make changes to their cluster and actively see its status change as as they apply their changes.
Finally, we wanted to optimize the functionality of our customized prometheus query component. Prior to our changes, users making custom prom queries were only provided the returned JSON object from their queries, with no accessible way to act on this information any further. Now, users are not only able to make the queries, but are given the ability to visualize the response from their queries with a time-series graph, pie chart, bar graph, or any one of the countless visualization tools that Grafana provides. What’s more, users can even save these visualizations as panels within a customized dashboard, and access any of these custom dashboards within the graphs components of the application. Ultimately, users now have complete control over the creation, access, and management of the visualization tools that VaaS provides them.
With all of these visualization tools in place, the last thing we needed to do was revamp the user interface. After all, next to the mesmerizing Grafana dashboards and other visualization tools we provided, the overarching design of the app was beginning to look dull. So in the closing days of our voyage, we provided one last visualization upgrade: the beautification of our UI. And with that last piece, we completed our portion of this glorious VaaS puzzle, and took our final turn home.
Over the course of our journey, we stayed mindful of our overarching vision, knowing that the product we are building today will be in the hands of real-world developers tomorrow. (Not literally tomorrow, hopefully). We held each other accountable to stay diligent and aware of our duty to these future voyagers. Like sailors navigating treacherous waters, with the impossible task of monitoring all of the containers and services they need to keep track of, we know how valuable we can be if we make our product right. Like a lighthouse shining its light through the night sky, guiding these brave sailors, we know VaaS can help them navigate those waters so that they can reach their destination smoothly and swiftly. So that they too can find their treasures and return these riches to their people.
We close this story with a message to the the next VaaS explorers. This is your project now. Do us proud. And please, above all else, fix these things:
- Configure the Grafana API to dynamically import Grafana dashboards so that you don’t have to hardcode dashboard IDs in the codebase. Additionally you can also use the API to manage authentication such that you can access dashboard management in a more secure way
- Instead of using a bunch of Load Balancers for services you want to import from the cluster, use an Ingress Controller in GKE.
- Simply go down the OpenFaas rabbit hole. Learn it. Love it. Live it. Teach it. Our rabbit hole was Kubernetes in the cloud. Yours will be OpenFaas. Make us proud.
- Make the UI responsive. VaaS should look good everywhere. All the time. Even on phones. Especially on phones. Use modals from the home page. React Router is an unnecessary abstraction.
- Use Redux for all of your state management. Don’t shy away from it. Run towards it. Be brave. Be bold. Have fun.
Please feel free to check out our VaaS website!
Young Kim║LinkedIn ║ GitHub
Ahsan Ali║ LinkedIn ║ GitHub
Rabea Ahmad ║ LinkedIn ║ GitHub
Stephan Chiorean ║ LinkedIn ║ GitHub
Ruqayaah Sabitu ║ LinkedIn ║ GitHub
