You have an awesome software team. They are following agile practices so that you can adopt change. But how many times was your development team able to make the change you asked for in the same hour or even on the same day?
The most common answers you would get are: we could get it done by next week as we are in the middle of a sprint or the change you are asking for would require a lot of rework and testing. All in all, you never get the job done the same night.
If you do push them hard, a chaotic release is made leaving everyone frustrated and scared. You end up with this fear that it would break something else in production.
Now imagine you did make the chaotic release. The nightmare scenario is when you realize that a bug is affecting data consistency and you realize this only a full week after the release. Rollback is scary.
Changing things, innovating and quick continuous experimentation is the need of today’s business realm. You must be able to do things to your software rapidly without actually having to worry about breaking something else. This is why you should consider microservices.
CHANGE SHOULD NOT BE CO$TLY
To change something in the system should be a natural affair. Adding a new small feature should not cost you a deployment. You want to be able to do 100s of them every month. You want to stay nimble and fast. It should not cost you heavily in time or money.
PUT HISTORY TO USE
Except for banking systems, the way software is built today focuses on managing the state of the system instead of recording facts.
For example: you have a profile picture functionality in your application. It allows your users to upload their profile picture and change it as well. As per the requirement, the software has been working perfectly fine for the past 2 years.
Suddenly, you want to find out how many times people actually change their profile picture. Even if you write the code now, you won’t be able to generate reports of your past data. However, consider this: What if the system had recorded a fact like Jane updated her profile picture? You can simply create a new report by running a query on these facts.
That being said, recording facts in such ways allows you to get your system back in a consistent state despite any other mishaps.
NEVER BE DOWN FOR MAINTENANCE
If you have a system that has to go down for every deployment or other maintenance reasons, you will start losing customers. You should be able to continuously make changes and deploy your application. With microservices, you only launch the changed facets of your application while still keeping everything else running.
DEVELOPERS & THE BIG PICTURE
Most developers prefer coding over actually understanding business rules or knowing the larger vision of your company. In a way, it’s also unfair to ask them to develop an inkling towards this. That being said, your goal should be to make 90% of your team redundant. Ideally, if your developer moves on, it should not bother you at all.
If your system is nothing but a set of several smaller services, each doing one thing and one thing only, the new developer only needs to know this one thing that the service does and this would be easy to comprehend because of its small size.
TECHNOLOGY MUST BE A DATING AFFAIR
If you are following the latest tech trends, you probably would have noticed how new frameworks come to life every day, become the new standard, and then suddenly die to a newer, better and apter framework. If you are married to a technology stack, it becomes a nightmare to move away from it and you have to forcefully embrace its constraints. It’s an all or none situation.
Microservices allows you to date different technologies. You should be able to use newer versions of technology or use a completely new stack for a new feature as you keep cruising along your way.
POWER TO DISPOSE OF ANY PIECE OF SOFTWARE.
Your code or microservice should be disposable. It should take you a day or two to write and deploy it. If you want to change it, you should be able to throw it out and write a new one in the same time period. That helps you change your technology stack or simply, just rewrite it better.
NO MORE TECHNICAL DEBTS
As the codebase grows, you generally incur technical debts. Your development team actually loves to use this as bait by saying things like- ‘If you want this change quickly, we will incur a technical debt and will need time to refactor later.‘ If you build using microservices, you probably will never hear words like this again.
I hope this conveys enough business reasons to consider microservices. I would be happy to answer any questions you have on jparekh@idyllic.co.
Idyllic Software has been working with microservices and event-sourced systems for a while now. The last 2 years of research and learning have completely changed the way we look at building software systems. Our focus towards anti-fragile systems has ensured that we never compromise on resilience in the software we build, even if it’s just an MVP.
We would be happy for the opportunity to speak with you or your team in your quest towards building resilient software systems that allow you to embrace change and work as a truly agile business.
Originally published on LinkedIn by Jinesh Parekh : https://www.linkedin.com/pulse/why-should-businesses-care-microservices-jinesh-parekh
While you’re here, check out Sid’s post on the first microservices meetup we conducted in Pune. Also, book your slot for the second meetup on August 7 – Take a deeper dive into microservices.
