Update: I added several key things recently after started implementing SRE concepts in Billie.
Site Reliability Engineering makes sense only if you bothered with Reliability. It doesn’t bring you much value if the most significant thing at current stage is delivering new features, say in recently founded startup this is probably not a good time to start with SRE.
SRE is a way to balance between the product Stability (Reliability) and Changes you’re going to make to the product, as changes are the most frequent root cause of the bad events. The core concept is when your changes breaking your product too much, you probably need to stop delivering these to the production and focus on stability. In order to switch the focus timely, you need to establish and track stability metrics. Also you need to define steps you going to take when stability promise to users about to be broken.
Let me share my thought after completing this superuseful SRE Course.
You need to make several steps to consider SRE path.
Little bit clarity on abbreviations those used by google guys.
SLA - service level agreement. This is the service perception boundary you shouldn’t cross. When user considers your service as bad, you didn’t match his expectations, so either you didn’t set proper expectations or you breached your promise on the service quality.
SLO - service level objectives. Same as SLA, but this is only internal promise and compass to meet user expectations, and this is a bit more tight because we don’t want to dissapoint user by breaching SLA.
SLI - service level indicator shows how you meet user expectation in some point in time. Normally this is ratio of good events to all valid events in some period of time.
How these relate to each other? Let me describe this in this little mantra.
We measure SLIs, which shouldn’t breach SLOs not to disappoint users by breaking SLAs.
Recently Oxid has presented the GraphQL API support and announced a hackathon-like event.
This experience was really refreshing and interesting. Having tight timeframe and some task in hand it was challenging to distribute efforts and get in sync with participants.
Our team had to deliver unified settings management solution like Google Chrome or Firefox has for numerous different things.
Late binding is a very precious idea.
Say, you have a docker image someone decided to use for the development. One created a huge bundle with all tools, bells, and whistles.
As time passes and you try to use it and then you miserably fail. Dependencies don’t met requirements anymore, most of the tools are outdated and should be bumped to newer version, initial SQL data has been changed and etc.
Configs are hidden and manipulated in docker image, composer.json is outside and you end up starring at this pile of crap.
Recently I’ve checked this website and styling became really aweful. After my digging it turned out one little busty thing was doing the crap.
Official Linkedin badge! Overrides default link styling!
<script type='text/javascript' src='https://platform.linkedin.com/badges/js/profile.js' async defer ></script>
The easiest way to turn it off is to change type=‘text/javascript’ to just ’text’.
You have also been decreasing my lighthouse score. Bye-bye little nasty thing.
I love datomic. Datalog is a definitely something noteworthy and even if you never going to use it in your projects, still it is worth getting your hands dirty. Despite all Datomic bright sides, there are some thoughts bothering me since I started using it more extensively in my pet project.
The Smalltalk is an extraordinary language. Firstly, this is a mother of all OOP family languages. Secondly, Java was invented as alternative for payed (sic!) programming language Smalltalk, and if IBM won the race with Microsoft a that time, things might end up very differently and Smalltalk could still be a hype.
Initially I’ve been exposed to Ruby, but only with Smalltalk I finally grasp lot’s of ideas in Ruby, so as the roots of the syntax.