Our development team is expanding more than ever before, therefore, DevOps Partner main responsibility is to enable the whole team to experience the full DevOps cycle (not just deploy something and operate for the team).
Giving the engineers responsibility and accountability to plan, code, test, deploy, and operate their product fast and reliable is our ultimate goal.
We’re a startup, that means nothing pretty here, you will be required to adapt in many situations and be familiar with a lot of open source components.
Our team split into multiple squads, each squad responsible for some components of the platform but we share the same responsibilities and help each other to fulfil bellow objectives:
As a Senior Member of the team, you are expected to keep yourself up to date with the best practices in the field, transfer it to our team members via internal training and maybe some public events.
The topics can be about:
Then apply to our daily operations, our platform architecture, give the team the direction to improve their development cycle.
We have a mixed architecture with a big monolith component together with many micro-service and micro-frontend. We have thousands of lines of bash script to spin up local minikube clusters for our developers (both backend or client side developers) to code and test their product on local, then use the same bash script to deploy to staging, uat, production on GKE using Github Action.
A lot of rooms for improvement here, such as:
We have A LOT OF E2E test cases. To organise the test, you need to understand the business domain, run them in a specific context and narrow down the scope to pinpoint exactly what's wrong.
Oh, did I mention that we have terrible memory leaks during unit-test, so we need to split the unit test into dozens of parallel runs as a work around?
Because of our startup architecture :) We have several GKE clusters with a few hundred pods on each cluster, half of them are open source components, each of them require different deployment and scaling strategies, we need your help on this, the number of components is increasing dramatically. Along the way you will run out of mem because of our Java based components, so be ready for that.
Of Course we have Prometheus, Grafana, Alert Managers, you of course need to operate them, make them reliable and scale. You will need to implement and improve the current tool set to automatically add a telemetry instrument to our internal service or write a custom exporter for the open sources that still don’t have one.
Btw, do you know any stress test framework that can run with gRPC? We want to compare how good our custom ad-hoc stress test tool is with that.