Apply reviews to the Stork post

_posts/2023-11-23-stork-latest-news.adoc

@@ -12,7 +12,7 @@ Since its initial release in January 2022, Stork has undergone significant devel
 This blog post takes a deep dive into the evolution of SmallRye Stork beyond its initial release, providing a detailed exploration of its fresh additions.
 But first, let's describe briefly what Stork can do for you.
 SmallRye Stork is a client-side service discovery and selection framework.
-It provides out-of-the-box integrations with Kubernetes, Eureka, and Hashicorp Consul, as well as a few selection strategies, including round-robin.
+It provides out-of-the-box integrations with Kubernetes, Eureka, and Hashicorp Consul, as well as a set of selection strategies, including round-robin, power-of-two-choices and best response time.
 But the most noteworthy feature of Stork is its extensibility. You can create your own service selection strategy or plug in your own service discovery mechanism.
 If you don't know it yet, a good way to get started is to take a look at our https://quarkus.io/guides/stork[getting started guide].
 
@@ -21,22 +21,27 @@ To further support your exploration, there is https://www.youtube.com/watch?v=fC
 Don't have much time? Don't worry, we have the https://www.youtube.com/shorts/F4Gd1I1zfjs[perfect video] to understand Stork in less than 1 minute.
 
 With the latest added additions we highlight how Stork
-continues to reshape the game of service discovery and selection from the client side.
+continues to reshape the client-side service discovery and selection landscape.
 
-== Programmatic Service definition
+Let's now have a look at the most interesting additions added to Stork since its initial release.
+
+== Programmatic service definition
+
+Initially, you had to configure Stork in the application configuration. You needed to configure the service discovery and selection (optionally) for each _service_ you wanted to discover and select. 
 
 Stork, from the 1.2.0 version, proposes a programmatic API to allow users to define the service discovery and selection configuration through code rather
 than through declarative or external configuration files. This means that you can use the full expressive power of Java to explicitly specify new service
 definitions and do manual lookup and selection. This is particularly beneficial when the configuration requirements of an application are not known until runtime,
 and it provides the ability to adjust settings without restarting the application.
 
 When using the programmatic API of Stork, you can:
-Retrieve the singleton Stork instance. This instance is configured with the set of Services it manages.
-Register new service definition.
-Retrieve the Service you want to use. Each Service is associated with a name.
-Retrieve the ServiceInstance, which will provide the metadata to access the actual instance.
 
-In the following code, we are using Stork programmatic API to set up and configure services with different discovery methods and selection strategies:
+* Retrieve the singleton `Stork` instance. This instance is configured with the set of `Services` it manages.
+* Register new service definition.
+* Retrieve the `Service` you want to use. Each Service is associated with a name.
+* Retrieve the `ServiceInstance`, which will provide the metadata to access the actual instance.
+
+In the following code, we use Stork programmatic API to set up and configure services with different discovery methods and selection strategies:
 
 [source,java]
 ----
@@ -79,38 +84,44 @@ your application.
 
 == Service discovery and selection strategies provided as CDI beans.
 
+The second noticeable improvement is the integration with CDI. 
+
 Users may prefer using a framework that leverages CDI mechanism to easily manage and inject dependencies and have a more testable and maintainable code.
 Stork can now do that. Starting from the 2.0.1 release, users can use the service discovery and load balancer as beans.
 For that, it looks for CDI beans during the initialization in addition to the SPI providers.
 It is worth mentioning that this enhancement also contributes to improving the Quarkus experience.
 
 
-== New Service Discovery approaches added.
+== New service discovery approaches added.
+
+We are happy to announce a few added service discovery strategies using DNS and Knative.
+
+With the Knative service discovery, Smallrye Stork introduces seamless service discovery through its serverless infrastructure, even when there are no 'pod' running.
 
-We are happy to announce a few added service discovery strategies leveraging the power of DNS and Knative from 1.2 and 1.4 releases.
-With Knative, Smallrye Stork introduces seamless service discovery through its serverless infrastructure.
 The Stork Knative service discovery implementation is very similar to the Kubernetes one.
+
 Stork will ask for https://knative.dev/docs/serving/reference/serving-api/#serving.knative.dev/v1.Service[Knative services] to the cluster instead of vanilla https://kubernetes.io/docs/concepts/services-networking/service/#service-resource[Kubernetes services] used by the Kubernetes implementation.
-Again, to do so, Stork uses https://github.com/fabric8io/kubernetes-client/blob/master/extensions/knative/client/src/main/java/io/fabric8/knative/client/KnativeClient.java[Fabric 8 Knative Client] which is just an extension of Fabric8 Kubernetes Client
+Again, to do so, Stork uses https://github.com/fabric8io/kubernetes-client/blob/master/extensions/knative/client/src/main/java/io/fabric8/knative/client/KnativeClient.java[Fabric 8 Knative Client] which is just an extension of Fabric8 Kubernetes Client.
+
 The DNS-based service discovery is also here to stay. When a service has registered one or more instances in a Domain Name System (DNS) server,
 Stork will be able to discover them by querying the DNS. This strategy is simple and widely used, so Stork could not fail to implement it.
 
 
-== New Sticky service selection strategy
+== New sticky service selection strategy
 
-The Stork load balancer family has been improved with a new one: the sticky service selection implementation.
+The Stork load balancer family has been extended with a new one: the sticky service selection implementation.
 
 The sticky service selection implemented by Stork refers to a strategy where a client "sticks" to a particular instance of a service until it fails,
 then it selects another one. It is also possible to configure a backoff period for specifying how long a failing service instance should be retried.
 This can be useful in scenarios where maintaining a consistent connection to the same instance is beneficial, such as when dealing with sessions or
 stateful applications.
 
 
-== Enhance the service instances cache expiration policy.
+== Enhanced service instances cache expiration policy.
+
+Since almost the first release, Stork has provided in-memory caching of discovered instances by extending the `CachingServiceDiscovery` class.
 
-From almost the very beginning, Stork has supported in-memory caching of discovered instances through the extension of the CachingServiceDiscovery class.
-As of version 1.3, this capability has been expanded to allow not only the retention of the cache for a specified duration but also the implementation of custom
-business logic for decision-making and data expiration.
+As of version 1.3, this capability has been expanded to allow the retention of the cached service instances for a specified duration and the implementation of custom business logic for decision-making and data expiration.
 
 This enhancement was driven by the specific requirements of Kubernetes service discovery as contacting the cluster too frequently can result in performance
 problems. So, out of the box, Stork Kubernetes service discovery now comes with a tailored cache expiration strategy to keep service instances until an event occurs.
@@ -175,10 +186,7 @@ You can check the https://github.com/smallrye/smallrye-stork/blob/main/service-d
 
 == Observability
 
-Observability refers to the ability to understand and gain insights into the internal workings and behaviors of a system through the analysis
-of its external outputs or observations. Stork becomes observable from the 3.6.0 release. This addition brings automated observability to the forefront
-of service discovery and selection providing a window into how Stork behaves in real-time. Now you can effortlessly monitor metrics such as service discovery
-and selection durations and error rates.
+Observability refers to the ability to understand and gain insights into the internal workings and behaviors of a system through the analysis of its external outputs or observations. Stork observability support has been integrated in Quarkus 3.6.0 release (release planned for next week). This addition brings automated observability to the forefront of service discovery and selection providing a window into how Stork behaves in real-time. Now you can effortlessly monitor metrics such as service discovery and selection durations and error rates.
 
 If you're leveraging Stork within your Quarkus application, now, you can easily check and analyze metrics such as service discovery and selection
 response times and errors directly in Prometheus. Check the https://quarkus.io/version/main/guides/stork-reference#configure-stork-observability[Stork reference guide] for details.