Subscribe to this blog

Follow by Email

Search This Blog

Building Microservices For Quick Wins - An Insight - Part 1

Introduction

Getting a quick win is hard because it needs multiple ideologies and practices to come together. It would ideally be a combination of least time to support the customer and to help the customer at the right point of their journey. By helping our customers to do the above, we help our products to grow steadily. Microservices can be likened to fast acting customer support, where we are building things in a faster and leaner way. Let’s talk about why an organization would need microservices in the first place.

Why Microservices?

As a first hand believer of picking the right tools for the right jobs, I would caution the reader that Microservices might not be a good fit for all organizations. You will have to take a stock of the needs, the pros and cons of an architecture style and then take a decision to either migrate or start building through the specific architecture. Microservices do help in a few things as the organization grows and it helps the product to be modularized so that it can developed independent of others.

Microservices is a style of architecture where instead of building a product as a single service, it is split into multiple sub modules and are developed as individual services. These smaller services are developed individually by different teams in different repositories without any need for a single big team to be present. Each service has a well-defined role and it doesn’t creep into other services. Each service can communicate with each other through APIs or any messaging channel.

The advantage is that the each microservice can be scaled, deployed, updated independently. The teams work fairly independent on their services and this helps them to move faster wherever possible.

What does Microservices Help Us to Achieve?

Microservices helps us to solve many problems that come with maintaining a huge monolith. When individual teams focus on a single problem to be solved, it becomes easier for them to build into their own service. It helps them focus on important features or bugs and develop them quickly. This leads to a quicker deployment as well since the deployment belongs to the smaller team and they release as quickly as possible. When multiple teams work simultaneously on different services, the development gets parallelized without entanglements. Also, if there is a need, a single service which has huge volume of requests, it can be scaled to solve the problem instead of the scaling the entire service as a whole. There is another intangible benefit that help us in building distributed systems - a contract based development where the other teams need not worry about what goes inside the system and can blindly believe on the contract specified by the team for their APIs. In a nutshell we can list them down as:

Focussed Development

Faster releases

Parallelized development

Scalability

Black box APIs

Technology Diversity

While building microservices, if care is not taken it could lead to a few problems of its own as listed down below.

Too much fragmentation could arise

Increased complexity of maintaining and integrating different services

Distributed monolith

Areas of Deep Dive Needed

There are some potential areas like Authentication & Authorization where the services can know who was calling and to check whether the request was authorized that needs to be baked into each service. Also backward compatibility might become an area where each service has to be compatible in their APIs with microservices that are still using the old endpoints. Service Discovery is also another topic which needs to be discussed in detail where how services establish themselves for others to be discovered. API Gateway is one another topic that can talk about how each call goes through to the services from the public consumers.

Since I have talked about the fundamentals of microservices architecture, I will be diving deep into these topics and how I have solved some of these problems at my work in another post.

Please subscribe to my email newsletter to receive the next post on microservices.

Jey, before microservices, rails introduced engines, we experience pros and cons. Now, headless CMS system have arrived, Ror has sugarcrm, though we have not fully investigated it, the speed and cost advantages of headless CMS seem to outweigh rails microservices and provide a true, independent platform for content authoring and editing which is separate from production. Consider these two factors, in many cause headless CMS may be a better choice than microservices.

Thanks for your views. I believe that headless and microservices share some common themes and are different on others. Both fits into their roles well and have their places. As I say, choose right tools for the right problems.

Post a Comment

Popular posts from this blog

Back in the day, when I was running my own startup, I had this fear of missing out on important meetings and I would make sure that I block my calendars with enough of them to ensure that I was on top of everything. In my opinion, this is a basic requirement any executive would have. Comparing this to the customer mindset, there is a very simple yet important requirement that customers want to know any updates to their service or product and how it impacts them at any given moment.

Customer Acquisition is Important. But Retention?

I would like to continue by telling a story that happened to me a few months back. I wanted to commute and I had gotten tired of the two popular cab services in Chennai. I wanted to try something new and got hold of another service provide who was a new entrant to the market. I had started to like their service and was wondering if I could switch completely to them and make my life easier. This is when the following incid…

I have a few tidbits about why to use microservices and why it makes sense to create few microservices as a side project and learn from the same. A lot has been said on why you should use microservices in the internet, that said, I look at it from a practical point of view and give you a very basic idea why we should use microservices and stop monoliths from becoming huge mountains of code in the future.
AdvantagesSimpler codebase(s) - Multiple projects with simpler code to maintain.Single responsibility - The microservice has a single responsibility and moves the developer from the mindset of developing everything together into separating multiple functional aspects into separate codebase.Test coverage naturally increases - since the codebase becomes smaller, the code coverage increases and bugs are figured out earlier in the development lifecycle.Readable codebase - Smaller equals precise and more readable and understandable. You have to understand this is different from simpler co…

The story begins when I encountered a HBR post that works out a few metrics about how companies that have highly engaged employees, outperform those that doesn't. My brain started thinking passively about these metrics and how it can impact business in a larger sense and I started thinking how we can have better engaged workforce that benefits both the company and the employees themselves.

Then, one fine day, when I was driving my car mindlessly, not knowing how my minded drifted to the same topic, I was again deeply thinking about the ways that we could engage employees more in simpler ways and get them involved in more ideation and creation process. This, in my opinion, will create more avenues for the employees to gather real world problem and brainstorm its solutions and help them in their growth for their careers. I thought this could be a real problem that can be solved for the knowledge workers as a whole. Then suddenly there was a huge Volvo bus in front of me siding from…