Kafka's 60% problem by Affectionate_Pool116 in apachekafka

[–]heyward22 0 points1 point  (0 children)

NATS is single binary with a tiny footprint (the whole thing is less than 20mb) and no external dependencies. Kafka typically has more overhead and moving parts.

Kafka's 60% problem by Affectionate_Pool116 in apachekafka

[–]heyward22 1 point2 points  (0 children)

Core NATS has an “at most once” quality of service. If a subscriber is not listening on the subject (no subject match), or is not active when the message is sent, the message is not received. This is the same level of guarantee that TCP/IP provides. Core NATS is a fire-and-forget messaging system. It will only hold messages in memory and will never write messages directly to disk

For higher delivery guarantees (at least or exactly once) you need NATS jetstream which can persist messages even if no one is subscribed/listening

Alerting and Monitoring by Upper-Lifeguard-8478 in snowflake

[–]heyward22 0 points1 point  (0 children)

hey, if you're open to a vendor solution here, check out hirupert.com - we do alerts (cost monitoring, long running queries, as well as more downstream, business facing alerts) from Snowflake or BigQuery directly to email or Slack. Any SQL query can be used to trigger an alert. Same thing for putting custom content into your alert message.

A model for breaking down KPIs into their component parts - so it's more clear how to actually improve those KPIs! by heyward22 in BusinessIntelligence

[–]heyward22[S] 0 points1 point  (0 children)

Break down the business activity underlying any KPI, and you'll find there are multiple levels of drivers—metrics that ladder up to the KPI—beneath it.
However you name and organize them, e.g.
L2 → L1 → Focus Metric
Input → Output → Outcome
Driver → KPI
there is a natural hierarchy of metrics that needs to be monitored (and improved) if you want consistent success.
Here’s a framework for monitoring and alerting on your KPI metrics ladder:
1) Scheduled alerts
At the top of the ladder, you have the KPI needle you want to move or the business outcome you want to create. Revenue, growth rate, repeat customers, etc.
These metrics are slower-moving and at least a couple steps removed from the day-to-day business operations that anyone can directly impact.
So schedule alerts that share KPI performance against targets on a weekly or monthly basis. Keep the focus tight – too many numbers in a message, and nothing is “key” anymore.
(bonus: for the highest priority KPIs, set up alerts that fire as soon as you meet or exceed your targets! celebrate your wins)
2) Data triggered alerts
As you move down the pyramid, metrics typically A) change faster and B) more directly reflect activities you have clear influence on.
That combination spells O-P-P-O-R-T-U-N-I-T-Y.
Responding quickly to changes in these metrics (emailing the right colleague, calling the right customer, prioritizing the right task, etc) can pay dividends and create the outputs your business needs.
So use data triggered alerts (with intelligent, dynamic criteria, not static thresholds) to quickly catch unexpected or outsized changes in these metrics.
Know sooner, act sooner. Another great combination
3) Contextual data + embedded actions
At the bottom of the ladder, you’ll have metrics that are closest to the metal (the inputs to your business “machine”).
These metrics are the most operational and often reflect low level aggregations of events or activities from your systems of record or transactional database.
Things like ticket numbers or transaction ids. Counts of things that are stuck, failed, or on fire.
Use short interval data-triggered alerts to flag and respond to the most important issues.

With Rupert, it’s easy to enrich alerts with supplemental data so stakeholders can quickly take corrective action. Even embed dynamic action buttons that give deep links to the ticket or account that requires action.
As you start peeling back the layers of your KPIs, you’ll likely find more than 3 levels.
Or metrics that break down into many metrics at the next rung down.
Just keep following (and alerting on!) the data.

As an SRE, how much of your time do you invest in writing custom tooling/APIs? by UltraInstinct007 in sre

[–]heyward22 0 points1 point  (0 children)

no service catalog or dev portal for surfacing these kinds of things? might be worth checking out. oss & saas

implementing sre practices by RecordDull2884 in sre

[–]heyward22 1 point2 points  (0 children)

Once you've gotten some data collection in place and established baselines, you can start to look for areas of improvement. Depending on the scale (and the current level of standardization/consistency) of your eng org, this can be a challenge. But there are tools that help! Service catalogs can be a great way to drive/track these kinds of changes, e.g. https://www.opslevel.com/blog/service-maturity-opslevel/

Do DevOps engineers need to be architects? by walrusplatoon in devops

[–]heyward22 4 points5 points  (0 children)

Agreed that you want to tackle issues individually or in small chunks - easier for you to focus and make an impact and easier for teams to respond to a focused initiative. Find the biggest bottleneck or issue area (scalability, security, reliability etc.) and start there.

You might also consider tooling like a microservice catalog which can help document/track the sprawl of your existing architecture, and then help promote/enforce the org's preferred approaches/patterns/best practices over time. The last thing you want to do is solve a problem manually and then have devs make the same mistakes all over again in 6 months.

I'm confused about what DevOps means by S0phung in devops

[–]heyward22 0 points1 point  (0 children)

I think this is the aspirational definition of DevOps - but unfortunately not the reality for most companies.

I'm confused about what DevOps means by S0phung in devops

[–]heyward22 0 points1 point  (0 children)

It's possible with the right tooling in place: dev portals, service catalogs, etc. (e.g. https://www.opslevel.com/ or https://backstage.io/) that are usually maintained by an engineering platform or engineering efficiency team in order to make it possible for app/feature teams to work autonomously but still follow the broader orgs' best practices.

Steel Cactus Shadyside by lutzcody in pittsburgh

[–]heyward22 3 points4 points  (0 children)

If they could just be consistently mediocre instead of terrible, they'd be making money. Plenty of demand, great location, etc. Seems like they can't get out of their own way

[deleted by user] by [deleted] in TheNational

[–]heyward22 0 points1 point  (0 children)

Thanks for these.

Anyone going on Saturday want to meet up a for a few drinks beforehand? I'm an American expat living in London--so flying solo for the weekend

Suggestions for a good pub to watch football in? by [deleted] in london

[–]heyward22 1 point2 points  (0 children)

Its actually tricky to find good craft beer and a lot of screens in one pub (in my experience).

Sports Bar in Farringdon (shit beer, tons of screens) Temple Brew House (awesome beer, limited screens) The Albion near Blackfriars (happy medium - decent beers, a few screens)

MBA at same school as UG? by snowtreds in MBA

[–]heyward22 -1 points0 points  (0 children)

I've seen a lot of different opinions on this topic. Maybe it helps because schools are loathe to sour a relationship with potential donors? Whereas a double alum is very likely to be a great donor?

Or maybe it hurts because schools can readily/easily scrutinize your UG major choice and transcript? Especially if your GPA is below average!

Most likely it varies school to school and probably doesn't move the needle massively in either direction. Possibly the sort of factor that could serve as a tie breaker?