Written by on 7 July 2015

Microservices: not a big bang theory

Following up on the previous blog posts on our move to a microservices architecture, this time I want to dive into how to actually manage the transition from monolith to microservices. It may seem like a daunting task, but as with anything big and scary, you’ll find it to be less so once you start bringing it down to a more manageable size. The keyword after all, is micro. Let’s get started!

We start by identifying a piece of functionality in the existing monolith that we can easily break off. Ideally, it isn’t too tightly coupled to other parts of the application and not the single most critical component. After all, we’re just starting off with microservices, things are likely to go wrong every now and again as we get the hang of it. It’s probably best to pick something that doesn’t have a huge impact when it does happen to fail.

Once we’ve chosen such a piece of functionality, we’ll re-implement it as a microservice. And remember, this can be very small. For us, some examples of services likes these were generating barcode images for a given string of numerical digits or resolving a postal code to address information. Something simple, easy to build, without any surprises.

Chipping away at the monolithIn the image on the right, you’ll see a part of our software landscape with Vanessa, our back-office application. Like with the examples I just mentioned, we take functionality out of this application and move it to individual microservices. One small piece at a time.

Now in most cases, the microservice in one way or another stores data. For this, it still relies on the Oracle database. This is temporary and only needed because the old implementation is still in place in the Vanessa application. The next step is refactoring the application to use our new microservice.

Hopefully, you will have applied solid software engineering principles when building your application and refactoring should be fairly easy. You may be even be able to implement the access to your microservices using an existing interface. If not, well, it’ll take you a little longer. But keep in mind that with each step you’ll reduce technical debt and make progress.

Re-using your new microserviceEventually you will have fully moved the functionality out of the original application and are now only using the microservice. Since its now easily reusable, you may even already use it in other applications. In our case, we can expose functionality previously only available in the back-office application to our webshops.

Thanks to the abstraction provided by the microservice, you’re now also free to change its internals without impacting its consumers. One of those changes could be moving the data out of the shared Oracle database into its own, isolated data store.

Moving the data to its own data storeAnd so, we end up with our desired situation. A fully isolated microservice, offering reusable functionality. The best thing about it is, is that throughout this process we’ve maintained a working system, which we worked on through small iterations. This allowed us to deliver value quickly, get feedback and continuously improve.

As we repeat this process, our monolith will slowly transform into a collection of microservices, making each iteration easier as we have less and less coupling and more reusable components at our disposal. All you have to do is get started!

COMMENTGive your two cents.

*