Building Applications with Microservice Architecture

Although there are good reasons to introduce microservices, the transition is not often easy. To implement microservice architecture successfully, your entire organization (business teams, development, IT support, security) must be ready to realign and optimize operations.

Whether building a new application, adding features to an existing one, or modernizing your legacy app, ascertaining whether you actually need microservices is the primary decision. As consultants with experience in implementing microservice architecture, we understand the complexities. Our team works with organizations to determine if microservices are a good fit and support clients in adopting the architecture through established best practices.

We recommend a gradual transformation where we incrementally refactor your application into a set of smaller components without tearing down the entire system and disrupting business.

Each microservice handles a different business functionality. So the first step is to identify a set of functionalities that can be grouped as a self-contained unit. A complex legacy application can have many such modules that can be converted into standalone microservices.

Our task involves identifying and prioritizing the modules for extraction. Modules that are least business-critical, easier to extract, most beneficial, or have particular resource requirements can be candidates for early refactoring. With every module converted to microservice, the monolith shrinks until finally there is nothing but microservices.

Microservices work better when used with DevOps to increase agility and efficiency. DevOps teams can work on independent modules in parallel speeding up development. As the number of microservices increases, automated continuous integration and delivery pipelines enable incremental releases while reducing manual errors. Continuous testing integrated into the CI/CD pipeline enables higher product quality.

The independent nature of microservices helps DevOps teams to achieve more in less time. Together, these two approaches can accelerate innovation and drive greater business value.

Containers are a perfect fit for microservice architecture as they provide a consistent environment from development to testing to final deployment. Using a virtual machine for each microservice can be a huge overhead and deploying multiple microservices in a single virtual machine can lead to conflicts between services. Because multiple containers can be supported by a single operating system, it is far more efficient to use containers than virtual machines for microservice architecture.

From a performance perspective too, containerization is advantageous. Containers being lightweight are quick-starting and can better match the erratic workloads of microservices-based applications. Fine-grained execution environment, ability to accommodate multiple components in a single operating system, and better response to erratic workloads often make containers the preferred choice for microservice applications.

To automate the deployment of containerized microservices and easily manage all your different microservices, we can set up container orchestration tools such as Kubernetes.

Monitoring thousands of microservices is laborious when compared to a monolithic system where you need to look at only one place. For visibility into the large number of micro components and easy debugging, you will need centralized logging and dashboard.

There are numerous open source tools to monitor containerized microservices. We can gather logs from each microservice into a central database using tools like Fluentd or Logstash. The database will index and store the data for future querying. Tools such as Kibana can be used to create visual dashboards representing the insights gathered from the log analysis.

A common challenge in microservice architecture is communication between the services. A microservice will not call other microservices directly; instead, the calls are routed through a message broker or API gateway. Microservices may also import/export data with the help of background workers.

When a user action requires multiple services to interact with one another across the network through remote calls, unavailability or high latency of even one of them can result in failure cascading across the entire application. The circuit breaker pattern can be used to gracefully handle downtime or latency of key services. This method helps the non-responsive service recover by reducing its load. The circuit breaker returns an error without making calls to the service after a certain threshold of failed responses. Connection to this service is reinstated only if periodic checks are successful; otherwise, the circuit remains open.

As microservices grow in number, handling service-to-service communication becomes even more challenging. Service discovery, load balancing, circuit breaking, authentication, and several other functionalities that are necessary for every individual microservice can be extracted to a separate layer common to all. Such an infrastructure layer to handle communication between services in a microservice architecture is the service mesh.

With most of the network communication offloaded to the service mesh, developers can focus on business logic. Microservices written in any language will work with the service mesh, which is language agnostic. Istio, Linkerd, and Conduit are some of the common implementations, with Conduit considered ideal for Kubernetes environments.

Security in a microservices environment demands a different approach than what is taken in monolithic systems. The inter-service communication happening over the network provides an opportunity for third parties to hack into the system. Our architects collaborate closely with security experts and apply the right tools to secure applications built in such decentralized environments.

Identity and Access Management

While we can build a custom authorization protocol, there are industry standards such as OAuth-based authorization services already built that can be used.

Zero Trust Model

Each microservice can be authenticated and authorized individually. Such a “never trust, always verify” policy ensures tighter security.

Defense in Depth

Applying different layers of security to the most sensitive services makes it harder for attackers to penetrate them.

DevSecOps

Integrating security into the CI/CD cycle with security unit tests, role-based access control policies, and container hardening measures make for better application security.