Bits and bobs

We live in a world which has come to expect everything to just work, all the time. At the same time we started to move to the cloud? Cloud is a completely different kind of beast to  self managed infrastucture.  Self managed mean control in all aspects of the infrastructure and total control when it comes to replacing hardware. In the cloud, a separate organisation is managing infrastructure and for many more clients, not just you. And if a piece of hardware needs changing, they just take it out. Imagine if they had to give a warning to everyone and wait until everyone was ready for the hardware to be replaced. It would never happen! A Shift in thinking So we live in a world where people expect everything to be working all the time, yet we are moving to a platform which can be pulled from under us without any notice. Seems kind of counter intuitive. However this is the exact catalyst needed to ensure our application are purposefully build with resilience in mind right...

Once we established we were on the microservice path, the question of just how would that look came up? We had established the problems and understood what we were trying to achieve, but what exactly is a microservice, and how do you go about building it? The importance of the first step can not be understated enough. If everyone understands the problem and really gets what we are trying to achieve, then microservices write themselves. Well not really, but by understanding what we are trying to achieve, the solution options can be assessed around a set of questions which would help drive the decisions being made. Can this service be deployed on its own, without affecting other parts of prod? If we had an influx of users using this feature, can we scale it out independent of the other components? If we did need to scale it out? do we need to scale out any other components as well? What happens if we had a network issue? would it still be able to do its job? If this service did ...

Agile has been around for a while now, and has been proven to be tricky to implement and returns questionable value. I have seen lots of different forms of agile, and sometimes the ceremonies get all the focus, and the essence of agile is lost. Especially for big corporates, they need to scale out this approach, so it becomes a playbook of steps you need to do. As we move into microservices, adopting agile was a critical aspect. Being able to change direction or approach means microservices can evolve as we go, rather than being predefined right at the beginning. This is an extrealmy important aspect of microservices. Generally in a monolith, the patterns are established and followed without question. Changing a pattern is hard, and needs commitment, and understanding from everyone. Microservices on the other hand, mean every domain can use a different pattern, and we can grow and develop the right pattern as we go. Whereas a change like this is massive in a monolith. Test and l...

It's been a while since posting something, but I feel like I would like to add to the millions of posts about microservices. I was considering avoiding adding to the already overpopulated mess of microservices articles, but I thought what the hey. I work for a large retailer in Australia and we were having a few issues with our platform. The very first step was to identify what exactly was our problem and to make sure we chose a path which would alleviate some of those problems. We had some technical problems, but we also had a bunch of business ambition which needed to be achieved along the way. Lets never forget, it the business which drives our decision right? There is a buzz around microservices at the moment. But it's important to understand your problem and make sure it is the right approach. The problems we had were Scalability Availability  Dependancies Domain knowledge Experimentation Long deployment cycles  Scalability The problem we had with scalabi...