Similar to a house, a microservice application consists of many individual parts all performing tasks both critical and non-critical for the successful execution of the application. Where a house needs rooms, plumbing, electrical, and a roof, a microservice application requires services, networking, volumes, and an orchestration environment. In this post I’ll draw similarities between building a house and building a microservice application.

You must start with a sound architectural plan

Saying you are building a microservice architecture is like saying you are building a two story house – vague and not very helpful. Just like the layout of the house is critical for it to function, so is the layout of your application. You probably don’t want all the rooms in your house to open into all the other rooms (and it may not be physically possible). Likewise, you don’t want all your services to have access to all the other services. Layout matters. Isolation matters. Egress and ingress are critical functions of your home and microservice application.

You’re probably saying that a house has a restricted footprint; different than a microservice application. Although, I bet your Ops team won’t be incredibly supportive if you come to them requesting unlimited memory, storage, and networks. I’d say that’s similar to the footprint restriction a home will have.

Visual modeling increases understanding

When working with an architect on your house, a picture is worth a thousand words. When designing the layout of your home, would having the architect only verbally describe the room layout, the routing for plumbing, and electrical be enough? How about with just a bill of materials? No!? Then a simple YAML file is not enough when designing the services, networks, and storage for microservice applications. Putting it another way, have you ever been in a conference room and only used words on the whiteboard to get your point across? Did it work? Probably not.

A single source of truth is critical

When you start building your house, you will most likely give “read-only” copies of your architecture to each sub-contractor. Of course you will also remind them that the copies are for convenience only, and changes can only be made to the master version. When dealing with multiple development and operations teams building and orchestrating a microservice application, do you let each team have a copy without knowing where the single source of truth lies? This could result in chaos and the old adage of “it worked on my machine” – #WorksOnMyMachine.

Architecting and building a house is a complicated process. The same holds true for a microservice application. Both require a sound architecture, which is easily communicated, and available to all team members. If you must distribute those architectural plans, make sure everyone knows where the single source of truth is.


Interested in learning more about Yipee.io? Sign up for free to see how Yipee.io can help your team streamline their development process.