My top Twitter threads on cloud, containers, and microservices for this year so far:

- Platform engineering
- API gateway vs service mesh
- @Kubernetesio debugging
- @Docker chaos testing
- Fast dev/test with Telepresence
- @buildpacks_io
- Microservice testing

A 🧵 of 🧵 s 👇
I'm predicting big things for the "platform engineering" space over the next year. Whether you ❤️ or 😡 the name, I think this is the new DevOps.

Watch this space for lots of knowledge sharing, innovation, and VC money 💰 !

A critical part of your platform is the communication infrastructure ☎️

I think there is a lot of innovation -- and potential confusion -- in the cloud native API gateway and service mesh spaces (and n/s vs e/w 🧭 )

If you've gone all-in on Kubernetes (or are going all-in) for your container-based platform, I provided some debugging tips based on an excellent @rawkode #Klustered session 🔧

Let's not forget about @Docker (who secured a $2.1B valuation this year with a focus on developer experience 🙌 ).

If you're using containers, you're most likely using Docker Desktop and its excellent UX and workflow.

My tips for testing resilience:
And if you're looking to get started with the new @Docker Desktop extensions, then why not check out the Telepresence extension for fast feedback when developing and testing container-based microservices 💻 ⚡ ☁️

If you're looking to build on your Docker Desktop extension for Telepresence setup, why not embrace @CloudNativeFdn's @buildpacks_io for an easy build with hot reload? 🔥

I've enjoyed using buildpacks since the days of Heroku. Here's my latest take:

And finally, here are some parting thoughts on overall strategies for testing your microservices-based systems 🧑‍🏫 :

I hope all of these threads have been useful! 🙏

Let me know here or via DM about any other topics you would like me to cover!

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Daniel Bryant

Daniel Bryant Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @danielbryantuk

Apr 22
Testing microservice-based systems is hard 😢

With that said, software testing in general is challenging, but to paraphrase the late great B.I.G.: "mo' services, mo' problems" 💰

Here are some key references and thinking points 🧵 👇
I think a lot of testing challenges come with a misunderstanding about coupling and cohesion 🤔

As I wrote back in 2018, these two core architectural properties massively impact your ability to test: danielbryantuk.medium.com/microservice-t…
Think about coupling and cohesion when designing microservices (yeah, yeah, I know, but I mean seriously think about this, and even do some upfront design) 🎨

codingthearchitecture.com/2017/10/11/evo…
Read 12 tweets
Apr 14
Are you looking to perform simple chaos testing on your @Docker setup to check your system's and microservices' resilience and security?

For example, do you want to spike CPU, memory, i/o, in a container and see what happens?

My top three tools to get started with 🧵 👇
First, you'll need some basic visibility/observability into what's going on.

I've recently been using @bcicen_'s excellent "ctop" (shown in my first tweet): github.com/bcicen/ctop 📊

Once I've seen something obvious, then I run "docker container top 20fa446aebf..." 🔍
The CPU burning container I'm showing above is using hub.docker.com/r/jfusterm/str…

There are a bunch of options to mess with CPU, memory, i/o 😁

(Note that this is a very old image, and although it's an Alpine base running simple Linux commands, this could still be a security risk)
Read 9 tweets
Apr 8
Looking to get fast feedback when testing microservices, but can't run all the services on your local machine? 🤯

Are you using @kubernetesio and stuck in a slow build-push-test cycle? 🐢

Let me show you the power of the new (beta) @Docker Desktop Telepresence extension 🧵 👇 Image
At last week's @Docker community all-hands, @scottcjohnston announced the new beta Docker Desktop extension functionality 🥳

@gtardif followed this up with a great live demo 🙌

You can read more about this in my summary blog post: blog.getambassador.io/happy-birthday…
In a nutshell, @Docker desktop (DD) extensions enable partners (and in the future, you) to add exciting new functionality directly to the DD UI.

The @ambassadorlabs team was chosen as one of the first partners to try this out, and due to popular demand, we added Telepresence Image
Read 17 tweets
Mar 27
Currently thinking about how API gateways and service mesh can work together, now and in the future:

- North-south traffic
- API as a product
- Migrating to the cloud
- Zonal architecture vs zero trust

A thread 🧵 👇
Traditionally API gateways have handled north-south (ingress) traffic and service meshes have handled east-west (service-to-service) communication

We used to think external access and choose an API gateway. And recently we used to think internal access and choose a service mesh
Increasingly, with a focus on design thinking (and rapid product iteration), migration to the cloud, and enhanced security, the boundary between API gateway and service mesh is becoming less clear
Read 24 tweets
Mar 12
I've recently been seeing increased chatter about "internal developer relations" or "internal devrel" roles 🤔

I'm also bumping into this role in companies we work with, alongside "dev enablement" and "developer experience (devex)" teams

Want to know more? Read on 🧵 👇
Having worked in externally-facing devrel roles for a while, this is my definition of devrel

DevRels bridge the gap between technology and user adoption:
- Generating awareness
- Education
- Creating tech demos
- Community building
- Empathizing with devs
- Acquiring feedback
A few of you may be thinking "but this looks like several roles across marketing, engineering, product ownership, and program management"

To which I reply: "yes" 😁

DevRel is a challenging role, and you'll wear many 🎩 s. It's also an extremely rewarding role
Read 22 tweets
Mar 4
In preparation for fixing broken Kubernetes clusters live on @rawkode's #Klustered event, I reminded myself of some of the core K8s debugging commands and techniques

Here are my top 10 tips for platform engineers debugging Kubernetes and the machinery underneath the covers 🧵 👇
First off, use kubectl to take a look at the cluster infra:

$ kubectl get nodes
$ kubectl cluster-info dump

These commands typically give you a good idea of where to start debugging, e.g. broken nodes, infra issues, resources
If kubectl doesn't work, it's time for some Linux debugging! SSH to the control plane node and run:

$ ps aux | grep kube

This will show you if core components such as the kublet, kube-apiserver, kube-scheduler are up and running
Read 19 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us on Twitter!

:(