Why Microservices fail??

-



Microservices is a buzz word in the tech community for a few years. Some have used it, others want to use it, and some of them are struggling with it.

What is the Microservice Architecture?

In simple terms, Microservice architecture is an approach to develop a single application as a set of small independent services; they communicate with each using a lightweight mechanism. Most of the time, this lightweight mechanism is HTTP resource API.

What are these independent services?

They are Autonomous services modelled around a Business Domain.

Autonomous

These microservices can evolve, change and deploy independently each other. That means we can add new classes, remove and change classes, change the schema of each service without affecting others. These services are loosely coupled.

Business Domain

Each microservice has its specific domain. For example, if we take Customer Service, it should be able to do all customer-related operations. But this is a simple example. We use DDD to identify the business domain and the bounded context. According to Eric Evans, “DDD flows from the premise that the heart of software development is knowledge of the subject matter.” What it says is that we must have a good understanding of the domain. You can read more about DDD in Eric’s book “Domain-Driven Design: Tackling Complexity in the Heart of Software”.

Microservices is the new Old.

Microservices is not a new thing anymore; it is almost 8 years old. You can find articles published in 2012. Yet this is still a buzz word. Over the last 8 years, Microservices has evolved and matured a lot. Event-driven architecture has contributed a lot to the Microservices. A lot of new tools technologies have been developed to support microservices.

When does It fail?

Microservices is a Silver Bullet.






Some believe microservices can solve most of their problems because it promises many things like improving productivity and speed, the flexibility of selecting technologies, easy to build services and availability. But they don’t see the complexity involved with it and infrastructure, tool requirement to implement it. We must have a good understanding of business problems, organization culture and microservices. Then only we can make the correct decision. From the developer point of view, doing microservices gives us the chance to work with lots of new technologies. That is what developers love. And some companies use microservices as a way to attract developers. But we have to think from the business perspective as well because that’s why we developed our application in the first place.

Microservices is better than Monolithic.

Some tech people think microservices is better than monolithic. These are two architectural patterns. An architectural pattern is a reusable solution to a problem that occurred in a context. You can’t say microservices is better than monolithic because they are trying to solve two different problems. If your monolithic application works without any hiccups, then why do you want to transform your system into a microservices? What advantage do you get doing that? When you are in a business where you want to deliver your features quickly to the customers to get the business advantage, then you must develop smaller services that can be easy to test and deploy. That is where microservices comes into the picture. For a dynamic business environment, microservices brings good advantages.

Failure to understand the Overheads.

Microservices comes with lots of overheads. Before moving into microservices, we must assess these. These are some of the challenges we face in microservices.
  • Service discovery
  • Interservice communication
  • API Gateway
  • Load balancing
  • Distributed data management
  • Distributed transactions
  • Distributed logging
  • Monitoring
  • Failover
  • Circuit breaker
  • Security
  • Testing
There are solutions for these overheads. Netflix OSS integration for Spring comes with solutions for most of these. I have seen some developers use these solutions without knowing how to use these things properly.
Distributed logging is one other challenging thing. In a monolithic application, request process inside a single application because of that all the logs are in a one log file. When it comes to the microservices, request can span multiple services. We must have a way to trace that request across multiple services. We usually use a correlation id for that.
Monitoring is another challenging aspect. In monolithic, we have one application to monitor. But when it comes to microservices, we have hundreds of services to monitor. We cannot rely on old generation monitoring tools; most of them are agent-based tools, and they are used to monitor long-running applications. A microservice may exist for a few milliseconds and disappear before the agent push metrics to the server. If we are going with containers then Prometheus monitoring is a better choice. It does not rely on agents.
Distributed transactions are another challenging thing. In microservices, we have transactions that span across multiple services. When we update record in one service, we want to update another record in a different service; handling this kind of situation is challenging. For this, we can use the Saga pattern but implementing Saga is difficult.
Tackling other overheads are also challenging. Here I explained a few crucial things.

Too many Technologies.

Microservices allows us to select the right technology for each service because different services have different requirements. We can fine-tune each service to perform better. But sometimes we misuse it, and this leads to an unmanageable amount of technologies. There should be a council to approve these technologies.

Start from the microservices.

I see a common thing when I read the success stories of microservices. Most of them started with monolithic. They have structured their monolithic to the best they can. They moved to the microservices when they can’t solve the remaining problems using monolithic. What they did was they solved their problems using microservices. They thoroughly understood their business and problems. Because of that, they knew how to adapt microservices. If you don’t have well structured monolithic, it is like going from a big ball of mud to orchestrating a lot of shit.





“If you can’t build a well-structured monolith, what makes you think microservices is the answer?”
Simon Brown

When to use microservices

  • When you have fully understood your business and problems.
  • When each module has different technical requirements.
  • When you can break your application into smaller services.
  • When you want to improve availability, maintainability and speed of delivery.
We use tools and technologies over others to get business value. Whatever we choose must be a business-driven reason; this applies to microservices as well. Microservices comes with many overheads. We must have a proper design to overcome these.

Comments

Post a Comment

Popular posts from this blog

Docker sizing Java application

-
Image
Many developers put java in docker yet they face many issues from development to running containers. Docker sizing Java application As  a Java developer, I faced many issues when dockerizing and running java applications. Running dockrized java application When we start our development we used java 8 as our runtime environment. We ran jars as separate processes (yes using java -jar ) in VM, at that time there was no requirement to dockerize applications and everything worked without any major issues. Later we experienced the need for dockerizing applications. Then we faced many performance issues. Our initial docker environment was just docker containers running in a VM without any container orchestration. When we compared dockerized application with normal java application, the performance of dockerized application was not good. When we set the memory limits for docker application, most of the applications threw  java.lang.OutOfMemoryError: Java heap space .   When we inves
Read more

Spinnaker Authentication with Keycloak

-
Image
Spinnaker Authentication with Keycloak In my previous  story  I explained how I deployed Spinnaker onto Kubernetes and enabled public access via ingress. In this short story I’m going to explain how I secure Spinnaker by enabling authentication with Keycloak. For this demo I used Kubernetes running on my Mac and also I’m not going to explain OAuth 2.0, OpenID Connect, all the features of Keycloak. Keycloak Keycloak is an Open Source software for Identity and Access Management. It is developed on the top of  Wildfly   server. It provides support for standard protocols like OpenID Connect, OAuth 2.0, and SAML. Authentication Spinnaker authentication involves three main components. They are, Deck  : Sinnaker UI. That is what you see when you access spinnaker. Gate : API gateway for Spinnaker. All the requests go through the Gate and check whether the request is coming from authenticated user. Identity Provider:  In our case this is Keycloak. Spinnaker Authen
Read more

Four Event Driven Patterns

-
Image
In this story I would like to explain my understanding of the Event Driven Architecture(EDA) and its patterns. I was assigned to introduce the CQRS pattern in my previous company. That is how I got to know about EDA. EDA comes with a lot of concepts like  Events, Commands, Event sourcing, Aggreate, Evet Reaplay  etc.. . I’ll briefly explain what EDA is and what common patterns are. Event Driven Architecture(EDA) EDA is producing, captureing , processing and persisting of Events . The concept of the EDA is not new. When we talk about EDA, we can identify two types of objects, those are  Event  and  Command.  We cannot do a proper implementation without knowing these two. Command Command is a request to a system to do something and sometimes expects a response for that. Command is very specific and it has a known destination. That means we know what is going to process and who is going to execute our command. Let’s take an Ordering System as an example. When we want to
Read more