This blog provides an introduction to Microservices.
Introduction
Software componentization has been the approach to simplify software architectures as soon as it starts getting too hard, complex to build, update or change.
Microservices simply represents an approach of componentization via services, A step in the right direction in the attempt to build out several smaller components as opposed to one large monolith. There are many other approaches, but this document talks about why we are using microservices and the benefits of the same. What is a Microservice and how does it work?
While there is no industry standard definition, a group of similar services that have common characteristics to form a microservice.
There are key advantages that we want to derive by implementing solutions as microservices. We can study that by understanding the characteristics of typical Microservices architecture. Characteristics of Microservices architecture.
Microservices are built to be independent Microservices are built to be independent as a component, and can be independently built and independently deployed. Microservices are grouped or organized around specific business requirements.
A microservice is typically built around a common business function, or specific requirements. This is the only logical boundaries for microservices as there are no other hard rules to define the same. By organizing as a business function, teams building a specific microservices can focus on solving all facets of the problem relating to a business function as opposed to a horizontally organized organization where each change impacts every team. Microservices can be independently deployed
The fact that it can be independently deployed means small pieces of our application can now be deployed in a silo without impacting the other pieces. And as long as there are blue/green deployments – customers won’t even notice changes to the platform architecture as it is getting updated. De-coupled
The other advantage of using microservices over a monolith is the fact that the components are typically de-coupled from each other and as opposed to talking to each other using proprietary, binary protocols – lightweight, non binary protocols are used to facilitate cross component communication. Decentralized data
Microservices are typically decentralized with their own logical data in isolation from other parts of the application. This again allows for changes to be done effectively (without breaking other dependencies). Microservices can be polygot; and blackboxes
Distinct microservices can be built on different stacks and built as black boxes hiding the complexity of the same from other consumers of each microservice.
How are we implementing Microservices?
At KloudOne, we’re big believers in open source. We’re both contributors and consumers of open source software and large parts of our stack consists of tried and tested, open source software.
We built out several key requirements that our microservices stack would need to have to be able to qualify to call it mature enough for production.
All microservices should be able to exhibit the characteristics as described above.
All microservices should be able to interface through a common gateway & load balancer that will allow rate limiting, access control and load balance requests.
All microservices should have application level metrics that are tracked using necessary tooling.
All metrics use an service registry, service discovery, and standardized authentication mechanisms such as JWT.
All microservices are organized horizontally around business lines.
Microservices can be written using any language / framework from scratch however at KloudOne, however we have a particular stack that we follow at Kloudone. Here’s a quick list of items, which we will cover ion much more detail later.
- Eureka OR Consul for service discovery
- Zuul reverse proxy
- Hysterix
- JWT based authentication
- Consul
- Envoy
- Logging of metrics using the ELK Stack (Eastic, Logstash and Kibana)
Conclusion:
While there is a lot more that we could go into – including how we have actually implemented Microservices, what are all the tooling involved and what were the actual benefits observed, this blog was to serve as a high level overview of the approach taken and I believe we have accomplished that.
Watch out for more exciting updates from the engineering team on this blog or subscribe to our mailing list to get automated updates from us.
