Skip to main content

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.

Connect with me at Twitter, Facebook, LinkedIn and Website.

Comments

  1. This was a good intro. Hope to find some more info somewhere.

    ReplyDelete
  2. 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.

    ReplyDelete

Post a Comment

Popular posts from this blog

Why Microservices?

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…

Hackathons - Top 4 Reasons Why You Should Participate in Them

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…

What's next to Conversational AI, Conversational Bots, Chatbots? Is it Conscious Bots?

This is an personal opinion essay from Jey Geethan about chatbots and its future.
Pre-Introduction Chatbots are programmatically independent software engines which mimic the way that consumers talk to a person and answer them in a appropriate ways - This could be the simplest way in which you can describe them. Also, you can imagine them to be a situation where instead of you talking to a real person over chat, social media, phone or email, you are instead talking to a computer agent who replies on the human's behalf.

Introduction Chatbots are almost everywhere now. Every banking website that you see, you have a bot icon at their bottom right corner. Website owners are also implementing chatbots for their websites where they feel that the chatbots can help their visitors in terms of information and also to reduce the amount of work done by the human counterparts.

In this essay/article, I would discuss about what the future of conversations are. What might happen to chatbots and what…
You will receive wonderful short stories written by him and inspirational articles once every month.