Microservice –Where is the start button?

What is a Microservice?

Wait!! I am not going to define again what a Microservice is.
A lot of experts have already done that. Here is an excerpt

[Microservice is an] Application as a collection of services that are

• Highly maintainable, scalable and testable
• Loosely coupled and Independently deployable
• Organized around business capabilities
• Owned by a small team

How is that different from the monolith you have been building?
The difference is the how?. This how is where the Engineering Culture plays a significant role

What to do first?

You agree that there is more than a tech stack involved in building your Microservice? Let us take a look at how to get started

Mindset, Mindset, Mindset - Condition the minds of the Engineers about how different their life is going to be building the Microservice. Prepare them for an approach that is not traditional.

Highly Maintainable, Scalable and Testable

Microservice is an evolving architecture. Scaling to the load and stepping up your feature velocity should be achieved without necessarily having to increase your team size. This is possible only when you have automate-everything approach and operating the service must be metrics-driven.

In the Internet Yuga, if you have an awesome service and you blink; the service is virally adopted.
Remember even the Moore’s Law is wrong. Scaling to your customer load has to be horizontal. More load should mean adding more instances and not just adding more cores or memory. And no matter how small you load is in the beginning always start with two instances of your service

Adding features and fixing bugs with the least turnaround time is only possible when you know you are not breaking something that is working, in short, a regression free software. This is doable only when you have the safety nets in the form of tests, plenty of them and all of them automated. Well spread to form a Test Pyramid

Source : martinfowler.com/

Another beast in your service is the configuration. To test your configuration and to manage change, treat your configuration as code. Tell your team and repeat with them “Configuration is Code”

When you run into an issue your first question must be “How did my test not catch this?”. Fix the test gap first and make the test fail consistently; then address the feature gap that fixes the bug; Later make sure that the test passes consistently. (Keep in mind the business continuity while you do so)

Make sure that the test is in the right layer of the pyramid. For example, if you wrote the initial test at the system level, push yourself to see if this can be caught at a lower level (unit_module_integration), write the test at the lower level and test it. Even more important step is to remove the upper layer test to maintain the beautiful shape of the Test Pyramid.
Rule of thumb is to keep the test as much in the lower layer as possible.

Question to ask yourself

• Can adoption be increased without causing increased workload on the team?
• Can you deliver-y- features fast with confidence of no regression?
• Do you have means to look at how your service is behaving?
• Can it self-heal?
• Can it proactively tell you if something goes wrong?

The answer to all those questions must be YES!

Loosely Coupled and Independently deployable

You have set out to build a Distributed Microservice. Not a Monolith and definitely not a Distributed Monolith.

A fundamental change in mentality must be to enable the different Microservices to evolve at their own pace. Draw those boundaries. If you want to bring in any change in your service and you are blocked because another service is not updated, then it is an indicator that you are building a distributed monolith

See these connected graphs. Each dot is one microservice!
On your left is Uber’s microservices and on right is Netflix. Do not strain your eyes reading them

The key takeaway from the two-pioneer architecture is that you-are-not-alone. Microservices exist in an ecosystem, loosely coupled having small responsibilities and fulfilling them extremely well.

Remember the aspect of scaling in the previous section? More loosely coupled your service are more easily they can scale.
For example, the external facing transaction API layer and the inner data processing layer would have very different scale characteristics. For the current load you may need to add more instance of data processing layer as the adoption increases without having to add more instances of the API layer if it can already handle the load

Always ask these questions

• Technically, can your Microservice run without any of its upstream or downstream services running?
• Can you make changes to your service and deploy, without regression, without changing other services?
• Do you have good contracts between the interacting services? Are those contracts in the form of automated tests? Answers to the above questions must be YES

Organized around business capabilities

This is one area where Monolith, SOA, and Microservice folks agree without an iota of doubt. But we all fall prey to Conway’s Law.
Melvin Conway’s way back in 1968, observed that:

/Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication structure. /

In fewer words, this means putting the Cart before the horse. Is your architecture designed around the business needs or organization structure? If your answer is latter then you are shipping your org structure, not business solutions.
Another good measure is to see how big is the team that is owning a Microservice

Owned by a small team

Microservices by nature must do small things and do them very well. This often means that if you have done things the right way then the team must also be small.
But did you notice how it is not said that it must be developed by small teams but the verb here is Owned?
In general, it means that the team owning a Microservice is responsible for making changes to that service. The ownership doesn’t stop there. Team also owns building, deploying, and maintaining the service. This is what we call Service Owners.

Question to ask

• If you are hiring, Does the job description have these words - design, build, deploy, and maintain/operate? The answer must be YES!

In fact, the same holds for those who transition from building Monolith to Microservice. DevOps will be the mantra of this team. More on DevOps in later blogs