Microservices Architecture | Microservices Solutions

What is it?

Microservices or a Microservices Architecture is an architectural approach in which a system is composed of multiple loosely coupled, independently deployable smaller components. These smaller components or services are built around business capabilities with minimum centralised management. It is essentially the opposite approach to a monolithic architecture in which a system would be built as a single unit. The following diagram demonstrates the comparison :-

Value proposition of the capability

One of the most popular arguments for Microservices is the ease of maintenance. Monolithic system architectures can become unwieldy and therefore difficult to support resulting in becoming difficult to change. Business critical systems of this nature can therefore result in poor organisational agility. In a Microservices architecture, teams are aligned with the Microservices and as with the Microservice itself, they do not have to be concerned with the rest of the system. This allows for independent, lightweight upgrades and changes that are much more manageable as Microservice changes do not rely on wholesale testing of the entire system.

Another advantage of Microservices lies in the reliability of the overall system. As the services are independently deployed and loosely coupled, a fault that exists in one Microservice will not affect the other services directly. There may be issues in data flowing from the faulty Microservice to others, but overall the healthy Microservices still function. The recoverability of the faulty Microservice is also likely to be easier, as an independent unit is all that is needed to be recovered. The services are typically deployed in lightweight containers, such as Docker, so recovery time is minimal.

Scalability is also a significant advantage in a Microservice Architecture. Rather than having to scale the entire system individual services can be scaled to meet demand. Consequently, costs can be lower as opposed to having a highly scalable monolithic architecture in which only one component of it needs to scale or be highly available.

Common uses or use cases

A Microservice Architecture is becoming increasingly common across many industries due to the aforementioned benefits. It is however much better suited to complex systems with many moving parts. The value proposition is much less attractive for simpler, smaller solutions that do not change regularly.

The most common use case for Microservices tends to arrive from the refactoring of legacy applications. Often organisations will have built upon a legacy codebase for many years and have started to feel the pain when trying to make changes quickly. Rebuilding applications such as these in a microservices architecture is an appealing proposition compared to lengthy, expensive projects each time a change is required.

Another common use case for Microservices is for real-time data processing applications. Applications such as e-banking, radar systems and traffic control systems that operate in real time significantly benefit from highly available, lightweight, easily scalable services.

Implementation Best Practices

There are many best practices to follow when implementing Microservices :-

The Single Responsibility Principle – Microservices should be modelled so that it has only one responsibility and therefore a single reason to change. This is so the services are much easier to explain, understand and implement
Separate Data Store – It defeats the purpose of having microservices if there is a single, shared monolithic database. Any change or downtime to that database would then impact all the microservices that use the database.
Use asynchronous communication to achieve loose coupling – To avoid building a mesh of tightly coupled components, consider using asynchronous communication between microservices. The preferred option is to use events for communicating between microservices.

Use an API Gateway – Instead of every microservice in the system performing the functions of API authentication, request / response logging, and throttling, having an API gateway doing these for you upfront will add a lot of value.
Dedicated Infrastructure – Isolate the microservice infrastructure from other components to help isolate faults and get the best performance.
Separate Release Train – Microservices should have their own separate release vehicle which is not tied to other components within the organisation.
Create Standards – Whilst microservices give you the freedom to develop and release independently, certain standards need to be followed for cross cutting concerns so that every team doesn’t spend time creating unique solutions for these. This is very important in a distributed architecture such as microservices, where you need to be able to connect all the pieces of the puzzle to see a holistic picture. Hence, enterprise solutions are necessary for API security, log aggregation, monitoring, API documentation, secrets management, config management, distributed tracing, etc.

Considerations

A key consideration for Microservices is the organisational structure and associated understanding of the implications of adopting the architecture. A Microservices approach is much more than technology, the technology enables and enhances the approach, though it’s really the organisation that adopts the Microservices approach. An operating model is a key component of a successful Microservices capability, and one that gives a “team” the full ownership of a Microservice. This means that the team will require many competencies such as DevOps, design, development and integration. The team should not need to communicate with different areas and should be able to solely focus on experimenting and creating new features of the specific service.

It’s also important to consider if Microservices is actually the right approach. Monolithic architectures still have their place, and are significantly less complicated than the sum of many Microservices. The cost of Microservices can also be much higher on the whole, not only with the amount of resources required, but also the cost of the individual resources can be much higher when considering roles such as DevOps architects and automation specialists. This may be a worthwhile investment if there is significant value, but can be expensive for simple, stable systems that do not require much change.

The management of Microservices is another area to consider. The services can soon proliferate and produce headaches similar to that of older point-to-point integration styles in which it can become unclear as to what service is talking to what other service and what the impact will be if a service is unavailable. It is important to prepare a strategy for managing microservices up front, also producing the appropriate standards and security principles before development.

Integration is an important consideration when looking into a Microservices Architecture. As described previously, an asynchronous approach is recommended and preferably event-based, though this isn’t always possible, and doesn’t always make sense. Again, this is an area which should be explored and planned in advance to ensure that the integration approach meets the business need. Communication is fundamental to the success of Microservices, after all it’s of little use if the components can’t talk to each other, though the overall journey or business process should be mapped out in advance to know where synchronous/asynchronous makes sense, and where state may need to be maintained.

Why Chakray?

Chakray are specialists in Microservices architectures, and more specifically in the communication between them. We have experience in designing, developing and owning Microservices for organisations, as well as establishing Microservices capabilities. Chakray are experts in common languages for Microservices development such as Java, Python, Ballerina and .NET, but also many technologies for managing, communicating and monitoring with Microservices such as WSO2, Gravitee, Confluent Kafka, Kubernetes, Docker and many more.