A pattern which you would notice here is that, a lot of tools would end up re-implementing what a service mesh would do for you, as one thing complements the other. (3/n)
You WOULD need tracing/monitoring/circuit-breaking/load-balancing and the other lot of features which would be required if you have more than a couple of hundreds/thousands of #microservices. (4/n)
Now should you go with a #servicemesh/go with individual projects to achieve this depends on the team & how they draw their pro's and con's on either of the choices. Lock-in to a specific service mesh/having a more granular approach to things and have a plug and play setup (5/5)
• • •
Missing some Tweet in this thread? You can try to
force a refresh
One thing which I tried doing differently this time with one of my side projects is to do TDD from the start. Someone may ask why? It's just a side project no? (1/n)
One reason is that, for some of my past side projects, when someone creates an issue/submits a PR. I wouldn't necessarily remember everything which I did/why I did x instead of y, when I would have authored it (more on how this can be improved later) (2/n)
Coming back to say reviewing a bugfix/feature PR. Having no coverage for those specific routines which were modified, would mean I either would have to rely on my gut feeling, or I would have to test it by pulling the changes. (3/n)
Releasing v0.2.0 for Bhola github.com/tasdikrahman/b…! This release comes with the ability to push SSL cert expiry notifications to @SlackHQ for the domains which bhola is tracking
It will alert for all the domains, which have already expired/are about to expire within the buffer period which you have set & send notification to your slack channel via webhook endpoint, periodically checking in the interval set by the operator, for expiration. (2/n)
This makes bhola, tackle the part of the problem for you where you don't have to keep checking the dashboard of bhola on which certs are expiring, rather it telling you proactively, on what are the certificates which need renewal and need your immediate attention. (3/n)
Another player in the container registry space, but none the less, I now don't have to play around with my @Docker hub credentials, to push the container image for my repo's, one less thing to worry about (2/n)
Also given the recent policy change with regards to bumping off the container images if not pulled for x duration was something which I didn't wanna get put into, although completely makes sense for the maintainers of the registry. I couldn't find anything specific for GHRC (3/n)
Have been using @github pipelines for one of my public repositories and it has been a great experience so far, having the CI experience (build, lint, run tests etc.) right in front of you, was something had been missing in their UX. (1/n)
Rather than delegating the CI experience to an external entity, which would create another lookup and another thing to worry about. This pretty much has taken the developer experience a step further. (2/n)
Another killer feature, was github packages! Which means, now we have a container registry too in @github (along with a few other formats of packages supported)! Which is again building on top of github pipelines feature set. (3/n)
Do you sometimes wake up, with a call by someone from your team, telling you some SSL cert has expired? Do you keep track of SSL cert expirations on your to do notes or excel sheets? Would you like to be on top of such x509 cert renewals? github.com/tasdikrahman/b… is for you (1/n)
v0.1 of Bhola, will give you a dead simple API, which you can use to ask Bhola, to track domains which have certs attached to it. It automatically checks for the cert expiration in the background keeping note of when is it expiring. (2/n)
The operator can set a buffer period, which would bhola, then use to see if it meets the threshold number of days, before the cert is going to expire, before marking the cert, that it needs renewal asap. (3/n)
Load average seems decent so far, although the ssh is unusually laggy, no process seems to hog too much of resource, will dig on this later.
In before I brick my router on a Friday night, as I update it's DHCP config to start pushing my @Raspberry_Pi 's IP as the dns server (running pi-hole), to all it's clients.