Microservice architecture (MSA) has gained popularity as an essential enabler of agility. Trailblazers such as Netflix and Amazon and many other large-scale web applications moved from monolithic units to microservices for reasons ranging from faster scalability to continuous innovation.
Currently, mid-sized and even smaller organizations are adopting this modular service-oriented approach to significantly reduce development time and get to market faster.
While rapid digitalization and distributed cloud computing favor microservice architecture, it need not be the default approach in every case. The key is to discern the need without blindly following the fad and this is where Barpun Solutions architects prove their mettle.
Microservice architecture refers to a software design style where different components are created and maintained as isolated services. Each microservice is intended to be small, handling a single business function and deployed individually without affecting the rest of the system.
Traditionally, applications were built as a single cohesive unit with all the functionalities woven together. Such software is usually deployed on a single machine and can only be scaled vertically. As the impracticality of this struck, logical units within the monolith were separated into physical layers such as User Interface, Server logic or Web Service, and Database for storage (tiered architecture).
Eventually, Service-Oriented Architecture (SOA) where the Web Service layer is vertically split into different services and the DB layer into corresponding storage solutions came to be a viable design for easy scaling. Microservice architecture can be seen as the progressive evolution of SOA.
Below is the representation of a sample retailer application with microservice architecture. Each service is responsible for a single business functionality. At the same time, the microservices communicate with each other for required information.
Large or small, enterprises need to continually meet the growing demands and expectations of their customers to remain relevant. While the traditional way of developing and deploying software cannot often keep up, the microservices approach offers certain benefits that enable organizations to stay nimble and competitive.
MSA allows for decoupled services written in different languages to coexist in harmony. So you have the freedom to choose the most appropriate tech stack for each business capability.
Globally distributed teams can work more productively when the solution is decomposed into smaller fragments independent of each other.
With different teams working on different components, development speeds up enabling business agility. You can add new components, deploy, and scale them independently.
You can isolate failures and modify a microservice without affecting the entire system. This allows for easier application maintenance as compared to complex monolithic systems.
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 to 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.
While we can build a custom authorization protocol, there are industry standards such as OAuth-based authorization services already built that can be used.
Each microservice can be authenticated and authorized individually. Such a “never trust, always verify” policy ensures tighter security.
Applying different layers of security to the most sensitive services makes it harder for attackers to penetrate them.
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.
Our client’s application was a rapid prototyping tool used for product design and development. The application was a monolith with tightly coupled client and server such that components could not be developed or scaled separately. Barpun Solutions team was asked to evaluate the technology stack, understand its shortcomings, and propose a new solution.
Besides major performance impediments, our technical evaluation revealed serious concerns regarding source code maintenance, code quality, and overall application scalability. We suggested redesigning the system as an N-tiered application with layers in a microservices model, where each module will be independent and loosely coupled with others. The hybrid microservice architecture was to make use of a single shared database instead of a database per service model.
We proposed complete automation of the new application life cycle. Build and deployment of the microservices were to be automated using Jenkins. With IaC (Infrastructure as Code) in place, deployment, monitoring, and management of infrastructure could also be automated. Dockerizing the application would help reduce resource utilization and enable rapid deployments while orchestration tools would simplify container lifecycle management. Finally, continuous infrastructure monitoring and log management using the ELK Stack was proposed.
To develop resilient and scalable modern applications or adapt a legacy monolith for the cloud, you may need microservice architecture.