Category: Microservices

CQRS and Event Sourcing at Idyllic

Our journey into microservices has led our teams to think more about building highly available and resilient software. A lot of this has been related to how we identify with the concept of the state. In most systems, a state is always tied to the database and losing this data would mean losing all information about the state system. Replication and snapshotting have been our solutions to ensure we don’t lose data in any way.
Event sourcing provides an interestingly different approach to viewing the state of the system. Event sourcing forces us to think in terms of events – events that affect the state of the system.
Systems that use event sourcing focus on recording events that affect the system in some kind of a datastore. This could even be a file. The state of the system is then generated by running through these events and using the relevant processors to operate on the data to generate the state of the system, thus allowing us to rebuild the state of the system in case our database goes down. This opens up a world of opportunities for making data/systems more resilient as long as the events have been safely stored.
CQRS stands for Command Query Responsibility Segregation. A command is a request that modifies the state of the system while a query is a request that queries the state of the system without changing the state. The data store that houses the events generally keeps track of whether a request is a “command” or “query”.
However, event sourcing is not a new concept and has been around for years and is well documented by Microsoft. Though the pattern has been usually popular with financial systems it’s definitely beneficial to every kind of system.  If you’ve ever been intrigued by how banks ensure they don’t lose details of your transactions and don’t have to be worried about losing their primary database, the answer is usually event sourcing. Greg Young, is an entrepreneur and engineer who has championed the cause of making event sourcing more accessible to all businesses through theEventStore.
Last Friday, Raza walked the micro services meetup group, in Pune, through the benefits of working with an event sourced system. If this interests you, feel free to reach out to our engineering teams in Pune or Mumbai on how event sourcing can be beneficial to you. If you’re interested in contributing to an open sourced project on event sourcing have a  look at http://github.com/supersid/Zuleikha_es
image6
image1 image7 (1)

Why should businesses care about microservices?

micro11

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 with 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-software.com.

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.

Microservices at Idyllic

Over the last one and a half years we’ve been constantly working towards finding newer ways to build more resilient software, faster. And, we’ve found that the lines between enterprise software development and building for startups has significantly blurred. The value of iterating and releasing software quickly has been universally acknowledged and our traditional methodologies for building applications fall short in more than a few areas. At Idyllic, our experiments with Burst Mode Development (TM) brought us to Microservices and we haven’t looked back since.

Rarely has there been so much excitement about an architectural design philosophy but we’ve learnt that the hype around it is, in fact, well founded. Concepts like Event Sourcing and CQRS alone, are worth their weight in gold and have completely changed how we look at software systems. Our quest towards anti fragile software has never been stronger. Over the next few weeks we intend to blog and talk about our journey in adopting and migrating towards micro services based systems in order to enable others who have been on the fence for a while.

Last Friday, we decided to share our year long journey by creating the first micro services specific meet up group in Pune, sharing our experiences in micro services adoption and some general best practices. While we focus on this, we’ll be working towards several open source tools and platforms that enable adoption of these principles and we hope to seek community support in building these products.
micro1 micro2 micro3

 

Technology Heterogeneity and Microservices

Developers are always akin to learning new technologies and are on a lookout to employ cutting edge technologies on projects that they are working on.

The chief technologist would often guard against this to ensure that abrupt technology choices are not made merely to satiate the developer’s geeky hunger. In the monolith world, the job of guarding is easier because the technology stack itself will throw in limitations and make it hard for the developers to plug in other languages.

Microservices makes it very easy for developers to use different technologies for various services they are building. If the application now has several different languages, it can become a nightmare for the organizations to maintain the application.

Microservices does give you this flexibility, but it should be used carefully.

Subscribe To Our Blog

Get access to proven marketing ideas, latest trends and best practices.

Next up home

Contact

Lets build cool stuff

Share your contact information & we will get in touch!

I want (Tell us more about your dream project)