Categories
Architecture Development

A kind of Microservices reading list

I’ve been working with Microservices for the last couple of years. It was kind of an uncharted territory back when we started. But the attention on the net and in the community has increased a lot over the past year and this spring and summer brought quite a few sobering experience reports. It is definitely not failing, but there are some real considerations to be aware of, and some of them are quite major non-technical issues. Culture and organisation needs to be changed to support working in a highly distributed manner with Microservices.

So if you’re considering Microservices, you’ll be in for an exciting ride. For many it makes sense, but do read these articles and watch the videos to make sure you don’t just make a gigantic leap of faith. Being prepared for the issues will help you move forward when the going gets tough. 🙂

So here we go:

And if you have only two hours, watch these videos. A very clear message by two very good speakers:

If you’re Norwegian speaking you might also want to check out our talk about our experiences at my current client: https://vimeo.com/album/1807533/video/105777592 .

Let me know what I’ve missed. 🙂

Categories
Development

Agility in operations

It seems like Facebok is pretty agile in how it handles new features and roll outs. According to an article on the High Scalability site they actually do major releases every week. One of the things that struck me was this:

Be Innovative, Not Safe. Fear of failure often shuts down the organizational brain and makes it hide behind excessive rules and regulations. A technology company should have a bias towards action and innovation. Release software. Don’t stifle genius. Rely on your tools and processes to recover from problems.

This isn’t a solution to problems, but it is a pretty accurate description of what I want to achieve myself. Making a release shouldn’t be difficult or scary. This means that we need tools and methods that:

  • Enables us to be relatively certain that we don’t introduce any errors
  • Enables us to recover from a failure, because we will eventually fail

Tools like JUnit, Fitnesse, Selenium are all tools that allow us to verify the behaviour of our application. They help us verify that what we have done doesn’t introduce any errors. This should enable us to roll out quite easily, but I think in many projects one doesn’t trust the quality of the tests and you fear rolling out because you don’t have a good recovery plan.

I think we have a lot of tools available to us when it comes to writing tests, we just have to get better at using them, and eventually improving the tools. Where we seem to be missing is the part where we do good rollbacks. Maybe we don’t even need tools for that? I’d like to hear how you do it, and what tools you use or are missing.

Categories
Development

Automate it all

When doing Agile development identifying and eliminating waste is a important practice. There is many things to eliminate, but one of the usual remedies is to automate a manual and error prone task. In my experience it is worth spending a lot of time automating tasks, not just because it saves time but because it gives you predictability.

Taking automation and predictability all the way would probably lead you to something like Continious Production that Paul Duvall has a post on. Johannes Brodwall also has some good perspectives on something similar.

It is sort of the holy grail of agile development, and would be something like what Jeff Sutherland said the are doing at Patientkeeper. They have deploy at the push of a button that enables them to deploy new versions to all their customers on a regular basis.

Spend time automating people. 🙂