Microservices enable applications to scale dynamically, facilitating levels of deployable agility that wasn’t previously possible. In this week’s blog, Masstech CDO James Whitebread takes a look at these smart little critters, and how we’re utilizing them in Kumulate.
What are Microservices?
Microservices are a method or direction of development which steers developers into building software in a number of single independent, highly scalable, flexible functions that can then be combined together to deliver the overall feature.
Each of these software elements communicate with other services through APIs, enabling them to be written in different languages or on different technologies. As each element is limited in functionality, it is much smaller in size and complexity than those systems built as Monolithic structures where software elements are inextricably interlinked and so can only be scaled together.
Within a microservices architecture there are a number of important tenants, in that services are:
- Independent in functionality
- Independently deployable
- Can be loosely coupled together
- Are independently testable
Developing using a Microservices architecture is growing in popularity due to businesses looking to be more agile and reduce bottlenecks in development time. The modular setup enables scalability, flexibility and reduced development effort.
Examples of companies using Microservices [1]
- Uber
- eBay
- Amazon
- Sound Cloud
- Capital One
- Groupon
An example of Microservices in action
Netflix is well known for using Microservices Architecture and was one of the early organisation migrating away from a Monolithic approach. With close to 200 million subscribers, and millions of hours of content being watched through this online streaming provider, it’s not a surprise to imagine the billions of API calls Netflix receive and service every day from customer devices. [2]
Implementing Microservices
In a greenfield state, defining an appropriate Microservices architecture can be straightforward, however in the brownfield situation of existing platforms and services, software is more likely to have been developed Monolithically. This means a substantial rewrite is in order to be able to transform those cumbersome, interwoven applications.
However, the benefits of migrating to a Microservice approach are plentiful:
- It is easier to monitor a single Microservice for availability, usage and to understand its reliability.
- Performance can be analysed to better understand the demand on a single Microservice, helping to predict any scalability needs.
- Developers can create services independently without needing close collaboration with colleagues, often resulting in more rapid development.
- Services are small in size and easy to understand, meaning that if a developer needs to move between projects, the time to cross skill is low.
- Increased ability to scale horizontally as there is greater demand on the service.
- Easier workload partitioning allowing service workload to be divided up per business demand.
- Easier to update and change particular services individually without the overhead of testing and validating the larger Monolithic service which would require a more substantial amount of testing.
- Easier to migrate between technology stacks if needed and as technology changes. A rewrite of a Monolithic system with many dependencies can be a considerable risk, particularly to delivery timelines.
Notable drawbacks of using Microservices
- As the number of services increase there can be additional complexity from development through to testing.
- Services need to be able to communicate with one another, this can result in additional effort within the development process.
- As the service number increases there can be additional effort in managing integration and management of the overall set of individual services.
How are we updating Masstech Kumulate?
Masstech is transitioning the Kumulate platform into a containerised approach, which requires some separation of services within the platform into a more Microservice based approach. This will enable Kumulate modules to be deployed on-demand, and spun up and down as required. When extra workloads hit, more modules will cope with the burst processing; when a module isn’t required, it’s microservice(s) are spun down, and are then not consuming compute processing and expense.
We certainly welcome conversations with our customers and partners who might be interested in deploying a container-based version of our platform and would be pleased to talk through the approach and explore your architecture with you. Get in touch with one of our technical team today for an in-depth discussion of how migrating to a container-based version of Kumulate will provide benefits to your business.
If you’re not yet using Kumulate, get in touch for a demonstration of the platform’s key components and how it can help you.
References:
[1] Taken from microservices.io
[2] More detail can be found in this very comprehensive review: https://medium.com/swlh/a-design-analysis-of-cloud-based-microservices-architecture-at-netflix-98836b2da45f
