Microservices and Microservice Architecture Explained

Everybody seems to be doing microservices these days, so what are microservices (or microservice architecture) and how does it affect your architecture?

Well, in the good old days (not so long ago), computer systems were developed in large units of deployment. A web-based system may have been developed as a web site with lots of code that directly read from and wrote to many databases. Deploying it was pretty simple – it was a single, large web site that needed to be installed on a target server. Other systems (batch systems, mobile apps etc) were developed in the same way.

However, developers discovered that a small error in one small area of the web site programming could bring down the whole web site. They also discovered that the code powering their applications tended to be tightly coupled. This meant that individual pieces of code were hard to re-use elsewhere and so a lot of copying and pasting happened! This led to having to maintain multiple redundant copies of similar code which was frustrating and expensive.

In a wider perspective, the tight coupling of code and creation of a single, big system meant that entire business operations and capabilities were copied and pasted between applications, rather than being easily re-usable between applications. This also meant that testing effort was duplicated between systems that performed similar business operations. For example, a pricing system re-used (copied and pasted) between systems could only be tested as part of testing the system as a whole. So if pricing changes were made, every system that included a variant of the pricing logic would need to be tested.

Deployment also proved to be harder than expected. Although deploying a single large system sounded easy, it meant that updates to very small parts of the overall system required the entire system to be redeployed. This meant downtime for unrelated aspects of the system which was inconvenient for users.

Finally, code ownership was frequently unclear between software development teams. This meant that problems went unaddressed and potential improvements were overlooked.

Microservices Architecture Benefits

Microservices are independently deployable, small, business focussed services that are easy to maintain and test, loosely coupled to other systems and components and (typically) owned by a specific development team.

Instead of deploying a single large system, a microservices architecture deploys many loosely coupled components (called services). These services typically communicate via a dynamic binding mechanism such as HTTPS, Enterprise Service Bus, TCP/IP or similar mechanism. This means that a small change requires re-deploying only the affected service and thus reducing downtime and the technical impact of the change. The trade off is a more complex deployment process as tens of services may need deploying rather than just one big component.

Microservices are focussed around business operations rather than technology. This means that business functions can be re-used across different computer systems without copying and pasting code everywhere. Referring back to the example above, we could create and deploy a pricing service that other systems will access over HTTPS (e.g. a RESTful web service). When the pricing mechanism changes, ONLY this service will need to be changed.

This in turn improves the testing situation. When the pricing mechanism changes, testing can be localised to only the pricing service (providing that the interface to the pricing service has not changed). This yields shorter overall lead times and lower costs.

Individual services within a microservice architecture are frequently owned by a specific team (this is an example of Conway’s Law). This means that there is clear overall responsibility for each service and each service gets the care and attention it needs to remain robust and secure.

In summary, a microservice architecture creates an eco-system in which components are:

• Loosely coupled
• Independently deployable
• Easy to test
• Focused on business objectives
• Owned by a specific team

If you would like to discuss microservice architecture with McKenna Consultants or any of our other bespoke software development services, then please contact us.