When I first started coding microservices a little more than two years ago, I imagined an entire world that worked in a service-oriented manner. However, even as few as two years ago, microservices weren’t taking off like they should because of one major flaw: the latency between services working together.
To fully understand how this reality has come to be, we first need to look at the logic that goes into microservice development.
The Thought Process Behind Microservices Architecture
Microservices are a new and unique way to approach development, and being the case, they require a new and unique way of thinking.
Think of a microservice like the black box on an airplane. It’s easily replaceable if anything happens to it or if it needs to be upgraded. (Stronger, boxy-er, boxes?) What’s important is that the people on the outside of the cockpit know it’s there, not how it works.
Similarly, a microservice should be easily replaceable or scaleable. Is your user base quickly outgrowing the login functionality of your site? Simply add more of your login API to accommodate.And just like the black box, the people on the outside should only care about what’s going in and out while understanding the API endpoint or function and its purpose.
That’s the beauty of microservices architecture - it’s easily replaceable, easily scalable, and easy to work with.
Microservices should be as decoupled as possible
Due to their independent nature, it’s ideal that microservices be decoupled. At least, as decoupled as they can be. This is easiest to accomplish if you use event-driven design as your framework when designing and using microservices. But, there are cases where dependencies are essential.
For instance, if your Account Service requires creating a Workspace within your Application, you cannot return a successful message upon registration until your Workspace Service has successfully responded.
If any chain of events below failed, you want the client to know something wrong happened and to try again:
Client -> Register (Account Service) -> Create Workspace (Create Workspace Service)
If the workspace creation fails, then the Account should not be able to log in. This is because the application expects a personal / default workspace to be available for this user.
In the case of wanting to ensure decoupling, a good example is an email service:
Client -> Register Account Service -> (Account successfully created event) -> Consumed by Email Service -> Email sent
However long it takes for the email service to fire that email, we could still tell the client that it’s successful.
Why are microservices essential?
Since these small services above are all separated, they can scale and live in small containers, saving your application tons of money. Each service has one responsibility, and can handle scaling on demand per the functionality required. If you have 1,000 people logging in every second, but not registering, the Auth service would scale, but not the workspaces.
The cool thing about KintoHub is that we’re enforcing services to work across multiple apps. If you have a game and website that both need an Auth service, they can share the same logic and server on the cloud. How this works is by ensuring we pass a key value “App-Id” to know where the call is coming from.
Microservices are just beginning to be exciting, and tons of cool solutions that make them easier to use are yet to be invented. 2018 and 19 are going to be one hell of a ride!