Recently I had a conversation with an ops engineer on my team about why micro-service architecture makes a lot of sense and why we should embrace it. Most of our applications are monoliths built over years and having new, small micro-services is something new for our environment.
“The term “Microservice Architecture” has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services. While there is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data.”- Martin Fowler.
So here are the points that should help convince your coworkers or boss about micro-services style of SOA:
- Small, easy to understand code base. Because micro-service application is responsible only for one thing, it requires less code, is easy to understand, is easy to reason about and has less risk of changes.
- Easy to scale. With a large, monolithic application you have to scale everything together. For example, you application consists of 2 components – registration and login subcomponents. you know the problem is in registration – but you can’t scale it separately. You have to scale the whole thing and waste resources. Also, with the AWS type of elastic scalability it’s quite simple to scale micro-service if demand for a particular service temporarily increased.
- Easy to throw away. Our field changes constantly at a fast pace, and what was cutting edge yesterday maybe quite outdated and slow today, or a vendor product you rely on does not fit the bill anymore or you want to move to open source alternative. Most of the time it’s easier to start from scratch with modern tools and languages than it is to reuse old, outdated technology. Micro-services facilitate this very well. For example, on my recent search project we decided to write from scratch a small micro-service with the latest technology instead of trying to understand and update what was originally written with Struts and Java 1.4. Needless to say, developers love to work on new projects and use highly productive tools to finish the project ahead of schedule.
- Easy to Deploy. With monolithic applications even one line code change require redeployment of the whole application. At least on the jvm platform. This could be a big problem for many organizations with its high degree of risk and disruption. Deploying micro-services is much simpler because the scope of deployment is much smaller. Plus you know where to look for problems if such arise.
- Ability to use a different technology stack. With micro-services the approach should be to use the best tools and languages for the job, instead of one size fit’s all. The same goes for databases. For example, recommendation micro-services can use neo4j and python because python has a lot of machine-learning libraries; event-processing micro-services may use java and cassandra because of multithreading properties of jvm and high scalability of cassandra. It also allow teams to try new technologies on small services without major disruption.
Smaller teams. It’s much easier and faster to work with a collocated, small team. Each small team can own micro-service and access other services via high level api. For example, a team in New York can be responsible for recommendation services and a team in India for content micro-service.
- System resilience. If an monoliths application stop working, then a lot of functionality stop working. On the opposite side, If one of the micro-services stop working – only small, particular functionality will be lost. It’s much more simple to build some resilience around smaller service. For example, failure of the order-processing system can be mitigated with message queues.
Do you see any other advantages that I missed?
I should note that micro-services present some unique challenges as well. There is no free lunch! What are those challenges and how to deal with them will be in my next post.