Microservice architecture for a WebTIS

Microservice architecture is a discipline of building software solutions in small, self-contained units of code called microservices. It’s essentially service oriented architecture to the extreme. Microservices are organized into a system of independent and isolated applications each of which has a single responsibility and delivers no more than a single business objective. Each microservice is a separate process with its own data source, programmed to communicate with others over the network.

Benefits using it

Such foundation naturally builds up an advantage in many areas of the product lifecycle. In management, for instance, the team of developers required to produce a microservice can be effectively shrinked all the way down to one guy, allowing them to choose the programming language, utilize bleeding edge technology, reuse libraries, and best practices. This might have already been a problem in a seasoned monolithic structure that was expecting a solid refactoring. Also, the learning curve required to understand a single microservice is moderate, perhaps equal to understanding the business objective in question.

Independently deployable applications in any quantities, of course, require a certain investment into continuous integration and continuous deployment tools as well as rapid infrastructure provisioning. But their existence really provides with more opportunities to benefit from regular releases and less lengthy automated tests, with virtually zero downtime and minimal risk to the system as a whole. Replacing one faulty microservice will not cause the whole product to crash in an instant. Automated monitoring and alerting will also play a crucial role in system’s good health and stability.

Scaling microservices is very rewarding, as they can be grouped by bottlenecks, be it CPU, memory, network or filesystem and deployed to appropriate server groups, or even to separate instances, perhaps when all of those bottlenecks are combined into one. In comparison with monolithic structures, this may become a decisive factor, when with the help of microservices costs of running the product efficiently can be reduced considerably.

Microservices for a WebTIS

In the Rail world a WebTIS is a Ticket Issuing System that operates online. It’s a complex system with many moving parts a journey planner, a reservation system a payment system, account management, financial reporting and integration with many industry system.

So what would a WebTIS as a set of microservices? That’s exactly the question we’ve been asking ourselves at Assertis over the last 12 months.. Our aging monolithic application is being gradually converted into a microservices system, by extracting responsibilities one by one, creating microservices and talking to them from the ‘old giant’.

All of this does have an impact on the design and operation of the system. Microservices are not a silver bullet and with added communication between each service there are now a lot more failure scenarios to consider. Someone would argue the failure scenarios were always there, now they are just more explicit. Either way the result will be a more robust system.

If tickets are issued by one system and fulfilled by another, what happens if the communication between those two services breaks down? Do you have a watchdog in place to ensure the process is running smoothly?

At times implementing microservices can feel like you are going down a rabbit hole as you are finding problems you never knew you had. But, that is part of the trade off. The system is more scalable and maintainable for some extra overhead. Here is a little illustration that will help you see the main components.

Development in the future

What’s next? When all the legacy code in the world has been moved into microservices and they all have been perfectly scaled, are there any possibilities for changes on the horizon? Will the code undergo some kind of globalization, when only a custom configuration is required to run a business? Those are maybe good questions for a hot debate in a pub, but the microservices architecture looks like a really solid step into the future we all should be prepared for, or at least become aware about.

Author: Nikita Batalov