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:
@@ -154,8 +154,8 @@ that defines how to reach those `Pod`s. This is how Kubernetes wires things up: @@ -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. @@ -262,8 +262,8 @@ a `Service`. Here is the diagram updated after adding two `Ingress` objects for `Alice` and `Carol`. @@ -330,8 +330,8 @@ each microservice to entries in Eureka. This gives us some benefits: seamlessly. @@ -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: @@ -463,8 +463,8 @@ Finally, I'm adding an overview of how Eurek8s is implemented. Here is a high level diagram: 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.