The term “microservice” is somewhat bogus, it means different things to different people, hence different approaches, but the principles of a microservice never change no matter your definition or the way you design it, if your application doesn’t follow this principle then its more or less another monolithic application distributed over several instances.
This post is the first in a three-post series, and in this post I will disambiguate microservices, explain the core principles that backs a microservice, the pros and cons, and things to consider while building a microservice, in the second series, we will take a “hands on approach” to building microservices with Nodejs and Docker. and lastly, we will go through integrating, deploying, monitoring and scaling our microservices. if you can make it through all these series, you will be confident to take on microservices completely and start implementing.
So! Lets Dive in.
INTRODUCTION
Sam Newman, one of the early pioneers of the concept of microservice and the author of “Building Microservices” gave a very simple, accurate, and complete definition of what a microservice is:
Small autonomous services that works together
These words “small” and “autonomous” are really the defining pillars of a microservice, but by saying small. how small is too small? or how small is too big? or does it even matter if my microservice is small as long as it follows the microservice principle?.
Small — In the actual sense, the term small is relative to the organization implementing a microservice and also to the chosen language used to develop the microservice, the thing is, what is big to an organization might be small to another organization, and what is big in Java might be small in python, but one thing is constant, as a developer we all have a sense of when something is too bulky, so you or your organization would be the judge of how small you want your microservice to be, but off course there are yardstick to help in keeping your microservice as small as it should be, the most important one you should note here is that “your microservice should focus on doing one thing well, and just one thing”, if your microservice is doing more than one thing, you are starting to introduce complexity, and this is where your microservice begin to flop, I proposed a simple formula based on what Sam Newman said in his book that can help set a boundary on how small your microservice should be:
So long your service is within this range, you are doing fine, and you will have a fully functional and effective microservice doing one thing exceptionally well.
Autonomous — Microservices are separate entity and should be treated as such, you want to avoid packing your services into the same machine, microservice should be deployed as an isolated service, this method might add some overhead but it gives you a simplicity that makes your distributed system much easier to approach, all communications between the services are via api calls, and these services need to be able to change independently of each other, and be deployed by themselves without requiring consumers to change.
Now that we understand the basic concept of a microservice, lets talk about the need to start developing applications the microservice way, the defining principles & characteristics, standards and shortcomings in building a microservices.
What makes up a microservices?
- Componentization via services: a component is a unit of software that is independently replaceable, upgradeable and deployable
- Organized around business capabilities: instead of putting our focus on technology layers while splitting team i.e UI teams, Database management teams, and Backend teams
- Focused on products not projects
- Decentralized Governance: Rather than using a set of standards written down somewhere, we are allowed to produce useful tools that we can use to solve similar problems
- Decentralized data management: While monolithic applications prefer a single logical database for persistent data, microservices prefer letting each services manage its own database either different instance of the same database technology or entirely different database system
- Infrastructure Automation: because we want as much confidence as possible that our software is working we run lots of automated,here, CI/CD is the way to go.
- Design for failure: In monolithic apps, the way we design for failure is by running multiple instances then load balance to the available resource when one resource fails but what happens when its a feature in your code that is causing failure
BUT WHY?
Why should I start considering implementing microservice architecture to my development process?, my application is doing awesome as a monolithic, why would I even need to break down my monolithic app into microservices, why? whhhy? whhhhhhy?
- Technology Heterogeneity: Microservices allows for us to use different technology stacks that is better able to achieve the performance levels required, meaning if one part of our system needs to improve its performance, we might decide to use a different technology stack that is best able to achieve the performance level required. like you can just wake up one morning and decide “Php is not scalable , I want to switch to Golang” or “a Key Value store will be better for my service rather than a Sql or Nosql database”, and you would do that conveniently without breaking anything, like you can perform gymnastics with your application without any fear. Isn’t that awesome?
- Resilience: In a monolithic system, if a small part of the application fails, almost everything or in most cases, everything fails along with it (Domino’s Effect). but, on the other hand, only that small part that fails will be out of service. We also run multiple instances of a monolithic application to reduce our chance of failure but with microservices, we can build systems that handles the total failure of services and degrade functionalities accordingly.
- Scaling: With smaller services, we can just scale those services that needs scaling, allowing us to run other part of the system on smaller, less powerful hardware, what a way to manage resources
- Ease of Deployment: Oh yea! everyone loves a speedy deployment process, but then, not everyone gets the luxury especially if your business is sitting on a giant monolithic monster. with this guy, if you make a very small consequential change to your application, you will have to redeploy the entire application. Not cool!
Shortcomings of a Microservice
- Expensive: For every service you create, you will have to provision a new application instance, database instance, monitoring separate and every thing that you will need to setup completely, meaning more money to spend, but really, if you design your microservice architecture well enough, it shouldn’t be too expensive for you, and even if it is, you should know it will pay off later on.
- Operational Complexities: Because everything is now independent, communication within your services now becomes a problem, you have to carefully handle requests, and manage your response properly, also latency will be a problem
- Database Management: It is going to be difficult managing multiple database across all your service, what happens when you need you need data from two services to be in a place so you can use them in another service? Can you see a big problem there?
- Testing: will also be really tedious, now you have to do all form of testing multiple times, you have to make sure your services integrate properly and errors are being properly handled, if this tests are not done properly there will be a lot of bottle necks which will break the whole flow.
Standards in creating a microservice
- Make it RESTFUL, interact with services via API calls, and API’s should be simple and effective
- Keep services small enough to stay small and big enough to add value
- Be consistent
- Always have a documentation for your services
- Distributes work with loadbalancers
- Use a source control platform for all services
- Continuous Integration and Delivery is advice
- Manage all logs in one place
- Use a Monitoring tool
- Team should be Autonomous in daily operation
Lets take a break here, in the next article, we will be going head on to creating our own little microservice architecture using Nodejs. You are curious about what we want to build right?….Stay Tuned!