Step 2: Creating a Directory of Services & DBs

10x Engineering Series – Microservices

This blog is a part of our series on “10x Engineering Series – Microservice”. The series covers two aspects:
— The 2-steps to lay the foundation of a microservice platform
— The amazing benefits that are unlocked
If you haven’t read the introduction, go here. Through our experiences, we hope to inspire you to build the right platforms at the right time!

Intro

Monoliths are ugly to maintain. With microservices, you might aggravate some problems. You have multiple repositories, all with their own code to initiate connections to dependencies, and to deploy the microservice with the right configurations. (urls, ports, credentials, etc)

As the team scales, the complexity of managing all the services becomes harder. And with multiple services doing their own thing, it might require a large devops team.
However, there is a very simple and easy way to get past this problem.

This blog is a tale of a single file. Investing in this magical file early will allow you to solve a ton of future problems with management of services.

Create a single file with all the credentials & discovery configurations for ALL services & databases.

The Directory File

This is what this file might look like - a simple key value store in JSON!

// Example of a config
{
  "USER_MYSQL_DB" : {
    type: "MYSQL_DB"
    addr_port: ...
    username: ...
    password: ...
    meta: { .. }
  } ,
  "USER_SERVICE" : {
    type: "RPC_MICROSERVICE",
    addr_port: ...
    username: ...
    password: ...
    meta: { .. }
  } ,
  ... : { .. }
}

Each key refers to a unique server running in your ecosystem. These typically would be – a database , a service , an event queue.

Standardised Libraries To Create Connections

To further leverage the above, let’s standardise the libraries that need to be used for these. Given you have RPC, you will have an RPC client creation function. Similarly, you can take your existing libraries for connecting to databases and event queues — and wrap them up.
What you will get is a very simple way to create connections using KEYs of the directory.

All details of fetching the configuration and connecting get hidden underneath.

const mysql_client = RPCFramework.initMySqlConn("USER_MSQL_DB");
const mongo_client = RPCFramework.initMongoConn("REQUEST_MONGO_DB");
const rpc_client = RPCFramework.initRpcConn("HELLO_SERVICE");
....

You get the point.

It is very simple to standardise & centralise this early. Then it becomes a cake-walk after.

If you had to move infrastructure, or change how you do service discovery – all you have to do is make changes in the configurations and/or update the wrappers.

Such a simple thing will allow you to:

• Reduced boilerplate for server setup
• Reduce boilerplate for client-server connection setup
• Create service-discovery between service-service & service-database
• Built automated CI/CD pipelines across multiple environments
• Solve for scaling centrally — aggressive scaling, time based scaling, etc
• Build CLI tooling

Summary

Standardising simple things early is a winning strategy!

This blog hopefully gave you a simple hack to create a central service directory that makes it very easy to create platform functions and do easy devops.

Something this basic unlocks a ton of interesting things we will come to in the other blogs.

Let’s jump to some amazing examples of what this and the RPC combined can help us achieve!

Next >> Tale 1: Zero Boilerplate Code!

Sounds like fun?
If you enjoyed this blog post, please clap 👏(as many times as you like) and follow us (@UC Blogger) . Help us build a community by sharing on your favourite social networks (Twitter, LinkedIn, Facebook, etc).

You can read up more about us on our publications —
https://medium.com/uc-design
https://medium.com/uc-engineering
https://medium.com/uc-culture

https://www.urbancompany.com/blog/humans-of-urban-company/

If you are interested in finding out about opportunities, visit us at http://careers.urbancompany.com