Before Diving in to Microservices Architecture

Here’s what I learned from diving to microservices architecture with a small team of five:

Everyone in the team need to jump in

Yes, everyone in your team needs to jump on the microservices bandwagon if you want the project to be successful. That is everyone must have experience in dealing with the complexity added by the microservices approach.

If people don’t understand the premise of microservices, then they will apply what they are known to work and that is monolith structure.

This has been a mistake and biggest hurdle I had from my previous project. I spearheaded a microservices approach in building our application but most of us are not yet adept with the kind of architecture.

The resulting application is that instead of a flexible application it becomes rigid to change. For example, we have a core layer that became a development bottleneck (difficult to boot and configure, not RESTful) because it was built using monolithic approach — to mitigate we try to add another layer of service on top of the monolithic application in order for it to become consumable by other services. Though it fixes the issue of adaptability it only adds to the complexity of the application. Now, we have additional layer to maintain and manage the release process.

Discovery

Making services talk with each other is fun but keeping their connection in sync will make you pull your hair out. While our project was in its infancy, we relied on hard-coding IP/host address of a service for another service that wanted to consume the other in a configuration file i.e. Service A making HTTP request to Service B. While this is good for one to three services, this has become a burden when we are adding more and deploying from local to production servers. Making sure Service B is connecting to the right domain or host of Service A requires DevOps team’s a lot of focus and patience not to pull their hair out.

A better approach for this is to use discovery tools like etcd and consul. The idea is that a service can now ask only the discovery service where another service lives to get an updated information.

Environment and Deployment

Another pain in the neck is keeping all members of the team working on the same development environment. It is a must that all developers working on the project have the same environment (OS). Otherwise, there’ll be a lot of weird behaviors when installing, reviewing or testing the code — missing dependencies, path not working, etc.

Docker, a tool to ship code along with the environment, would have been the ideal solution for cross-platform development but this needs a lot of dedication to maintain and updated as well. In a small team of five with a tight deadline, this is a nightmare.

I’m looking at AWS Lambda or other Serverless stacks out there as the future for building applications. The ability to upload a compiled zipped code to the cloud and let the cloud provider handle the runtime and scaling of your application helps you focus on what really matters. Configuring environment and managing servers doesn’t really add value to users perspective and it only hurts the client’s pocket.

We should be focusing on developing and solving business problems at will without a lot of fuss and ceremonies.

Monorepo

The microservice architecture will spawn a lot of services - there’s no end to that. The beauty of this approach is that you can plug-and-play or replace services at will without disrupting the whole system — as long as the contract is the same as the previous one. The problem though is you’ll have a ton of services that need to be managed.

We tried mitigating the difficulty of deploying, code review and testing by working on a monorepo i.e. one git repository to host all services categorized by folders.

Instead of a developer doing tons of pull requests across multiple git repositories and having it code reviewed. We solved it by treating services as one release sprint. It’s not the silver bullet approach but it works for the team.

Instead of a developer doing tons of pull requests across multiple git repositories and having it code reviewed. We solved it by treating services as one release sprint. It’s not the silver bullet approach but it works for the team.

HATEOAS

It is necessary that your service must be explicit on how it can be interacted and how it behave. HATEOAS helps consumer of a RESTFUL service become aware of the endpoints next step. Here’s an example:

http -j POST :8080/orders itemId=123

When I create an order, the response should help me decide what’s the next thing to do. It also makes the API more discoverable.

Conclusion

Microservice architecture is not the silver bullet. It’s all about pros and cons and how you can live with the trade-offs tailored to the needs of the project and your team.

One solution leads to another problem. But we must evolve and struggle well in order to succeed.

Thanks for reading.