1⃣ Kubernetes API is the de facto standard for #on_cluster application orchestration. It serve as axiom among #Devs creating distributed applications and #Ops keeping these applications running.
2⃣ These apps depend on 3rd party services such as DBs, key-value stores, file buckets, queues. Kubernetes API, tools, & practices can manage #off_cluster resources as if they were on k8s.
Examples: @crossplane_io, GCP Config Connector, AWS k8s Controllers, Azure Service Operatr
3⃣ Multicloud complexity is the ugly reality for many organizations. Kubernetes-like APIs are used to orchestrate #multi_cluster application workloads. Example projects and managed services:
Azure Arc, Anthos, Red Hat Advanced Cluster Manager, Hypershift, kcp.io
4⃣ But there is #empty_space between the business logic and the infra, left to developers to fill in.
K8s APIs bring consistency & reuse of tools & practices boosting the effectivenss of #Ops teams. But they do not address the #Devs’ needs at the same level! Dapr fills this space
5⃣ K8s helps #Ops keep a large number of containers running, but it doesn’t help #Devs implement reliable distributed apps using their language and framework of choice.
✅Dapr with Pub/Sub, Service-invocation, and other distributed building blocks helps.
6⃣ K8s helps #Ops provision and manage third-party resources uniformly, but it doesn’t help #Devs using myriad different libraries in different languages to consume these third-party services in a uniform fashion.
✅Dapr bindings/connectors help.
7⃣ K8s helps deploy containers in multiple clusters, but it doesn’t help the creation of portable multicloud applications that are independent of cloud services semantics and integration patterns.
✅Dapr abstractions help.
8⃣Dapr improves #Devs’ productivity the same way Kubernetes improves #Ops teams’ productivity.
9⃣ If interested in more, check out the blog post for the in-depth version, or watch the recording of my talk from DaprCon @daprdev.
Let me know what you think. 🙏 thenewstack.io/the-flywheel-e…
• • •
Missing some Tweet in this thread? You can try to
force a refresh
USE vs RED - which is the better methodology for analyzing the performance of microservices 🤔? 🧵
Begin observing the performance characteristics of apps before the production rollout using Google's four golden signals. #ShiftLeft ibm.com/garage/method/…
The RED method takes an externally-visible (request-driven) view of the workload. For every workload, it checks request rate, error-rate, time each request takes. weave.works/blog/the-red-m…
Slack’s Kafka journey to operational excellence at scale! Context and lessons 👇 🧵
➡️0.7 petabytes of data
➡️10 Kafka clusters x90 nodes
➡️6.5 Gbps throughput
💪small-but-mighty ops team slack.engineering/building-self-…
Challenge➡️ solution
Automation ➡️Chef, Terraform, CI/CD to build, release Kafka & ZK
Hot spotting➡️make partition counts to be a multiple of the broker count
Replication➡️limit the replication bandwidth
Imbalance ➡️ Cruise Control
Tune clusters➡️Chaos engineering with dark traffic
Slow cluster recovery➡️Enable jumbo frames
Visibility into cluster metadata➡️ Kafka manager
Visibility into the health of the Kafka consumers➡️Kafka offset exporter
Islands of knowledge➡️One-page runbook
📕Another week, another book review📕
"Learning Dapr"
tl;dr: A different perspective on distributed systems from the creators of Dapr. Introduction to @daprdev combined with creators early insights in one book 🧵👇
Starts with a detailed introduction to Dapr philosophy and architecture: Dapr is a language-neutral, unified programming model that abstracts infrastructure details from developers
What are the cloud promises & challenges; and how Dapr simplifies the creation of portable cloud native applications. With examples for service invocation and pub/sub through Dapr