Bits and bobs

Moving from a monolith to a microservice Architecture is hard. It is important to understand what are the issues with the monolith before jumping right it. If you understand what your problem is, you can make sure you don't introduce the same problem in a microservice ecco-system. Distributed Monolith When we start realising the benefit of building new things and linking them via an API, it can be quite tempting to make everything a service. The problem starts to arise when one service calls another which calls another. This leads to a bunch of services which are dependent on each other. You end up back to where you started in a monolith like structure, you end up with a distributed monolith.  The problem with Monoliths is that everything is accessible. It seems like a good idea at the time, sharing code seems like a no brainier. Usually there is one big catch-all project which contains all the utility type code. Once shared between other parts of code, you can never change i...

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...

I recently did a scrum master certification with scrum alliance, and the 2 day course somewhat changed my opinion of what Agile is and what a scrum master should be. When talking agile, there is a multitude of beliefs and behavious implemented across a broad range of industries. Some are as little as the use of stand-ups during development to full blown "to the letter" implemented as described in many literature found on the inter-web. My previous view on Agile was focusing on the work, and what it meant to be Agile, adapting to change and incorporating change as you go. However, after this 2 day course and during the time I was working as an Iteration Manager, I came to see that Agile is much more than that. The key benefit of Agile, is actually the focus on building the team, the retrospectives and inwardly focused self review. Being Agile and adapting to change is a given, but a team that truly embraces Agile is highly effective and efficient team....