diff --git a/_posts/2020-02-12-eureka-kubernetes.md b/_posts/2020-02-12-eureka-kubernetes.md index e4a98a8..c6307ae 100644 --- a/_posts/2020-02-12-eureka-kubernetes.md +++ b/_posts/2020-02-12-eureka-kubernetes.md @@ -78,8 +78,8 @@ accounts following a fairly standard architecture. Here is a (very) simplified view of one account:
- - + + Eureka architecture (source)
@@ -154,8 +154,8 @@ that defines how to reach those `Pod`s. This is how Kubernetes wires things up:
- - + + How we deploy a microservice in Kubernetes
@@ -178,8 +178,8 @@ nodes. Not to any of the resources in the **overlay network** like Let's see the diagram updated with a VPC peering between both AWS accounts.
- - + + Our starting point: legacy and new infrastructures
@@ -262,8 +262,8 @@ a `Service`. Here is the diagram updated after adding two `Ingress` objects for `Alice` and `Carol`.
- - + + Adding the Ingress
@@ -330,8 +330,8 @@ each microservice to entries in Eureka. This gives us some benefits: seamlessly.
- - + + The full picture
@@ -411,8 +411,8 @@ Eurek8s will continue to enable the full migration of all workloads. By the time we're done, both environments will look like this:
- - + + All microservices are migrated to Kubernetes
@@ -463,8 +463,8 @@ Finally, I'm adding an overview of how Eurek8s is implemented. Here is a high level diagram:
- - + + Eurek8s
diff --git a/_posts/2024-02-10-how-about-we-forget-test-types.md b/_posts/2024-02-10-how-about-we-forget-test-types.md index 7c01b23..41e211e 100644 --- a/_posts/2024-02-10-how-about-we-forget-test-types.md +++ b/_posts/2024-02-10-how-about-we-forget-test-types.md @@ -178,7 +178,7 @@ to hold a rational conversation, among themselves and with stakeholders.
A shape sorting toy made out of wood, with coloured pieces