The benefits and considerations of upgrading to microservice architecture.

Written by Chris Wiles – Technical Director at ZetaSafe

It may not be possible to create a ‘perfect’ microservice architecture from your existing system on day one. That’s OK. You will start to get the benefits of a microservice architecture as you begin to develop. You may never end up with a dictionary definition microservice architecture – that’s OK too. You will still enjoy many of the benefits offered by a microservice architecture.

There are many reasons to consider a moving to a microservice architecture; maybe you have a monolith system, a single huge code-base which is a spiders web of complexity. Perhaps you have problems training new developers on the system as its so big and complex. Perhaps you have problems and expense hosting the system as its not written to work on new cloud hosting environments. Your product development may be slow and expensive as the code base is complex, and developers who know how to program the old architecture are expensive and rare.

The premise of a microservice architecture is simple; create many small specialist services, each of which runs independently. These small services make up the entire application. There are many advantages to this approach, and some considerations too.

Core Advantages include:

• New developers can easily and quickly understand and master each service. This will lead to better code with less bugs.
• As systems run independently, and specialise at a few tasks, testing becomes easier, leading to better code with less bugs.
• Most cloud providers provide a means to host micro services. You worry about the code, not the hardware, maintenance, backup, disaster recovery (to a point), server patching, server hosting ……..
• A change to a particular microservice will have no effect on the other services. Its less likely a single bug will take down your entire system.
• It’s possible to use different languages for each service – maybe some languages are better than others for the specific function.

In a perfect Microservice environment, each service is completely independent and dedicated to a specific task. In the real world this may not be achievable when factors such as development resource, time, cost and risk are considered. A phased approach may well be more appropriate.

A phased approach will provide many challenges. Proper planning will pay dividends as your project progresses.

Database access is perhaps one of the biggest issues. Each microservice you develop may well be looking at the same datasource. Until you split your database up this will be an ongoing issue. Databases typically limit their number of connections, and a monolith application would typically use a connection pool to ensure the number of connections does not exceed the database max. Each microservice will use a database pool, and require a number of connections. Without a database connection pool solution you will be immediately limited on the number of individual, or instances of the same microservices live at any one time.

It will become apparent that as you split services there will be an element of common code which will need to be shared. Its not ideal, but a fact of life. An example may be an authentication service which understands what a User object is, and the User service which allows user related operations. The definition of what a user is common to both services. Designing common packages which can be used in each service will be required.

Authentication is a huge one. How will you authenticate access to the microservice? You cant go wrong with JWT Tokens, it prevents a lookup for authentication privileges on each request, keeping things fast, its not for all systems though.

Monitoring each service will be required. With your monolith system, you knew whether your system was running, but now it may be that a single microservice has stopped – how do you know? Some health check, with regular checks from something like Monitis will be required. Each microservice should have a health check feature.

Each microservice will produce logs. You will have many logs, in different places, and perhaps on infrastructure which you cant access – like Azure Webapps. You will need to monitor these logs as realtime as possible, especially in the early days – look at incorporating a log service to your microservices, something like papertrail is excellent. In a single place, you will be able to see in realtime, all your microservice logs.

Communication is essential in any development team, especially when a team is embarking on a new architecture. Slack is the obvious choice for team communication. Not only does it just work, but web hooks from deployment, monitoring, and logs can all be added.

Good management is essential. Its easy to get this wrong. Start small, get the basics right. You don’t need to create thousands of microservices each literally doing a single task.