Showing posts from February, 2017
Microservices in the Chronicle World - Part 5 In this part we look at putting a micro service together as a collection of services, and consider how we can evaluate the performance of these services. We introduce JLBH (Java Latency Benchmark Harness) to test these services.
Microservices in the Chronicle world - Part 4 A common issue we cover in our workshops is,  how to restart a queue reader after a failure? The answer is not a simple as you might think.
Microservices in the Chronicle World - Part 3 One of the problems with using microservices is performance.  Latencies  can be higher due to the cost of  serialization , messaging and deserialization, and this reduces  throughput . In particular, poor throughput is a problem because the reason we are designing a  scalable system [ 1 ]  is to increase throughput.
Microservices in the Chronicle world - Part 2 In  Part 1 , we looked at how we can easily create and test components which expect asynchronous messages  in and produce asynchronous messages out. However, how do we turn this into a  service ?
Microservices in the Chronicle world - Part 1 At a high level, different  Microservice  strategies have a lot in common. They subscribe to the same ideals. When it comes to the details of how they are actually implemented, they can vary. Microservices in the Chronicle world are designed around: Simplicity- simple is fast, flexable and easier to maintain. Transparency- you can’t control what you don’t understand. Reproduceablity- this must be in your design to ensure a quality solution.
Micro-services for performance Microservices  is a buzz word at the moment. Is it really something original or based on established best practices? There are some disadvantages to the way microservices have been implemented, but can these be solved?