Showing posts from 2017

Reviewing Exception Handling

Reviewing Exception Handling When developing an application it can be hard enough to get the happy path working, let alone worry about what might happen when something goes wrong. I have asked a number of developers recently what they do when they get an exception and usually they log it or pass it back to the user. What are some alternatives? If you have to pass on the exception how might you do that? Read more by following this link to the new blog!
Distributing Common Java APIs Distributing data stores vs Private data stores in Microservices Distributing data containers e.g. Maps, can be a way of avoiding having to think too much about distributing your application. Your business logic is much the same, and it is your data collections which are visible to all your services. Using centralised or even distributed data stores have a number of scalability issues, as it requires very low-level data access to be distributed in a generic way which isn’t optimised for particular business requirements. Distributing business components with private data stores is the favoured approach of Microservices and it limits the "surface area" of each service which reduces security issues, performance considerations and gives you more freedom for independent changes to service’s data structures. In this review, I will be focusing on distributed data containers, largely because the interfaces are available in the JDK and
Modelling Microservice Patterns in Code Service Interactions There is a number of simple interactions a service can support. Which pattern is best for your application can depend on what an existing application expects, and what latency requirements you have. Broadly speaking these interactions fall into client-server and peir-to-peir messaging. For peir-to-peir messaging, one approach to take is  Lambda Architecture  however from supporting GUIs, client-server models can be easier to work with. I feel it is important to design components which could be tested and debugged together, as in a monolith, but can be deployed as multiple  right sized  services to different threads, JVMs, or machines. Read more by following this link to the new blog!
Simple Asynchronous Microservices using Lambda Architecture. Lambda Architecture Lambda Architecture is a simple, powerful, though limited example of a Microservice. As it is so simple, you want to use it as much as possible, to expose the more complex services/component in your system which cannot support this interaction model. Read more by following this link to the new blog!
Microservices are about applying a group of Best Practices Microservices Denial A number of times clients have said; they can’t imagine their organisation using Microservices. I found this surprising as I know those people are using many of the principles of Microservices already. I can understand that they feel no need to join the hype around microservices, but the reality is, like it or not, you are most likely using some of the best practices Microservices advocates. Read more by following this link to the new blog!
Bad String We have a program here that has two threads printing messages alternatively. However, if you change a  String from  "cC"  to  "cc"  it doesn’t print anything, WHY? . . .  Read more by following this link to the new blog!
A JDBC Gateway Microservice A deep dive into a low latency microservice We look at a microservice which can run in it’s own JVM, can perform JDBC updates and queries via a persistent queue for in bound request and a queue for results. In previous posts I looked at the theory behind there low latency micro-services so lets have a look at a micro-service which can do something useful.
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?