Moving to “Micro-service” and “Serverless”

Abstract

“Micro-service” and “Serverless” might be most popular words on software architecture in recent years. Amazon is definitely the pioneer on these areas. I’ve constructed or reconstructed several systems with “Micro-service” and “Serverless” architecture during my 7 years in Amazon. The followings are what I’ve learned from these projects.

Why Micro-service?

Although “Micro-service” is very poplar today, it is not a right reason to adopt the technique just for its popularity.

In Amazon, my team had adopted “Micro-service” architecture very naturally. Frankly speaking, the situation had pushed us to “Micro-service”architecture while our system and team becoming large.

According to my experience, the moment you detect the following bad smells is the time to think about moving to “Micro-service”architecture.

 

Bad smells

In Amazon most of the projects are started from a simple (monolithic) architecture and then scaled by duplicating directly.

The monolithic architecture normallyrelates to single continuous deployment pipeline.

Some bad smells as the following would be detected while the system and organization growing more and more larger. These smells would appear in the different stages of development process.

 

Plan

Nowadays, when starting new projects, engineers like me get used to start from “Google” to check if there are some existing implementations can be leveraged. Unfortunately, sometime the existing implementations might be not compatible with your current technique stack. For example, the existing implementation and the monolithic system are not written in same programming language.

 

Code

When submitting the codes, you always get the integration conflicts. More and more code branches were created by the different teams for the different purposes. And the