Planning and Adopting Microservices

No Comments 416 Views0

In an increasingly data driven world, micro services are becoming a key method of consuming resources both inside and outside of the firewall. From TFL to Spotify, Amazon to Amadeus many major businesses and government organisations are creating open API environments and micro-services are increasingly part of these setups.

It is easy to loose MicroServices Architecture within the broader Service Orientated Architecture toolset, but the adoption and move to Micro services can be much quicker especially with existing monolithic environments.

SOA abstracts key elements from each other and can be performed from the code level right through to the system level. This can end up being huge amounts of work with very little real short term benefits. One of the things to consider, is the approach of layering types of APIs : Experience (what an end consumer gets), Process (the way things work together) and System (data access) APIs all work together.

One of the key benefits to Micro Services is that they can be implemented and deployed rapidly, you can start achieving the benefit of this before you have a fully matured API stack to publish and be consumed. The nature of this means that Micro Service endpoints can be implemented to replace the Data Access Layer (System API) very rapidly and using multipole different backend storage points.

The easiest way to look at the deployment of this is using a SQL database. Our adoption method would be to implement a microservice with direct affinity to a table. Lets look at an example with a teacher<->classroom<->student type environment Micro Service adoption is especially useful with highly normalised databases, which we will use in the following example.

Micro Service 1: Teachers.

The database contains the teachers id and the teachers name. We can easily use a micro service endpoint to add, edit and remove the teacher.

Example: /api/teachers

Micro Service 2: Classrooms

The database contains the room id and the room name, and maybe some information regarding its size and amenities. Again a micro service can be deployed to add, edit and remove the room information.

Example: /api/classrooms

Micro Service 3: Student

Again, we have a database with a student id, student name and maybe some other data like phone number, email address etc. And once again the endpoint allows us to add, edit or remove the students from the database.

Example: /api/students


We have now very quickly and efficiently exposed some specific data sets which can be managed by multiple different sources as necessary. Now we want to link a teacher to a classroom on a specific day. For this we have a database link table with some contextual information: teacher_id, room_id, bookingdate, bookingduration.

Lets expose this as: /api/bookaroom

Its now possible for us to create all our data in the database very efficiently and quickly without needing to know or do anything about the existing system. We now have several data endpoints which can be used by our applications to create and manage our data. Multiple systems can now easily access these endpoints to make calls and view/edit the data set.


The next part is adopting a good API strategy. In this case, we can implement an API gateway on top of our microservices that could for example: allow any teacher to book a room, but not add students/teachers. Or allow a student to update their own details using their own unique token but not edit anything else.


Leave a Reply