You've summarized it really well, been using k8s for the past year on a large microservice infra and it's been a pleasant experience. Most problems were flaws in the way our cluster was setup or our misunderstanding of the config options k8s provides.
extremely valid point. The initial setup isn't the challenge, it's the endless tweaks to make it fault tolerant. For anyone looking into k8s, take time to research best practices for monitoring and readiness probes.
Hmm.. it's definitely tough to begin on a codebase with 0% coverage.
The first step is to stop the bleeding so begin adding unit tests for any new code you write and be sure to factor this effort in with your sprint estimations.
In parallel work top down with high level integration tests written against feature flows. E.g., As a user when I select this then I expect this. This doesn't mean you need to actually use BDD gherkin library for your test runner but at least frame the context of these in that regard since you don't care about the minute details of the underlying code, just the experience of the user story.
And lastly, don't just write tests to write tests, try to understand what is important to cover against because there is nothing worse than maintaining barely useful tests wired up to legacy data fixtures.
From Post-WW2 to 90's Gulf War Harley-Davidson built bomb parts in the same factories the bikes were built.
Why are you not outraged about this and saying things like 'Harley assisted the military in killing humans for the past 70 years with metal casings that may be used on your softail?'
I mean why stop at google? The private industry has always been supplying the government with goods and services, some of which go to the military.
Because the precision scored Tomahawk shell casings they produced caused a net decrease in lives lost, or were used to kill members of an utterly vile regime's military.
Keep at it and evaluate every few weeks if you feel ready to throw yourself into the arena and take some interviews. You may never feel ready due to the sheer amount of languages and knowledge you think you'll be checked on, that means you need to narrow your focus and specialize in a popular stack that you personally enjoy working with to get your foot in the door.
It is absolutely reachable. A personal path for reference:
2012: Graduated college with a non-comp sci degree (although had tinkered with tech, software, linux, etc since a teen)
2012-2013: Took comp sci MOOCs.. Obsessively learned python and built throwaway projects. Took code challenges weekly.
2013-2015: Got a job as a manual test analyst. Used python to automate testing, got promoted to test lead.
2015-2017: Took a job as Lead QA Engineer. Learned C# for the job. On the side picked up React and Django/DRF for building out SPA/microservices. Began getting serious about clean projects on github and kind of branding myself as a developer (personal landing page, etc). I couldn't keep recruiters off me from my linkedin, stackoverflow and github profiles. Was like ok.. I'm ready... it's time.
2017 (mid): Studied the hell out of algorithms and data structures. Did tons of whiteboarding practice and began taking interviews. Signed up for some tech recruiting apps like hired and opened the recruiter floodgate. I had 2-3 phone interviews a day for 3 weeks. Then a few in persons per week. Not one whiteboard session. Some would send code challenges. The rest asked if I could send them a github project that we'd review during the interview.
2017 (mid)-Present: Now a Software Engineer at an established startup working with brilliant peers and some of my favorite stack.. A massive kubernetes cluster built on Python, Go, React, and ElasticSearch services.
So from 2012-2017 there were many points where I doubted I'd land that dream... and then boom! As soon as I got the balls to throw myself into some interviews for the position I wanted I found it and now I no longer feel like I have to grind away every evening to stay sharp since my job is doing that for me now.
We've got about 30+ backends in python all wrapped in docker containers. Majority of the team was pure vim before I joined and they're slowly converting to pycharm after seeing how nicely you can setup a remote interpreter against a docker container. And it has vim bindings so you don't have to re-learn new hotkeys.
I remember, on my laptop with pycharm and docker (and the virtual machine docker lived in), the RAM usage was just excessive. I am by no means a minimalist, but data-science stuff was barely impossible with 16 GB RAM.
Also, I strongly dislike PyCharm. I am a vim guy by heart, but I am generally not against IDEs. VS Code is okayish. For C++ development, I really loved Visual Studio. But PyCharm just feels wrong, bloated, slow and baroque
What I do is create the virtualenv locally that docker would also create, and point my editor to the local virtualenv. It gives me all of the intellisense locally. I still need to debug within the container/shell for the moment but I'm hoping there's a pathway coming for vscode that pycharm already has.
Got about 80+ services. One repo per service, each service has it's own kubernetes yaml that details the services deploys to the cluster. K8s has a huge ecosystem for monitoring, versioning, health, autoscaling and discovery. On top of that, each repo has a separate slack channel that receives notifications for repo changes, comments, deployments, container builds, datadog monitoring events, etc. There are also core maintainers per repo to maintain consistency.
For anyone that has begun the microservice journey, kubernetes can be intimidating but way worth it. Our original microservice infrastructure was rolled way before k8s and it's just night and day to work with now, the kubernetes team has thought of just about every edge case.
