Microservices

In this blog, I want to talk about how our technology stack has evolved over time while transitioning from Enterprise to adopting Microservice architecture as a main stream development practice and share some of the lessons learned. Tech stack for us has evolved from being a Monolithic Enterprise to Cloud to now Microservices. During Enterprise days, it looked something liked this: At the app layer, we had a desktop client written in Windows form and WPF. The app would talk to the Service Layer which was SOA architecture written completely in C#. It was the only language allowed for us to use. These were monolithic and stateful services communicating to each other over WCF. We used SQL server as backend storage. All this get deployed on premise meaning our clients buy our software and host it on their own hardware. I work for Finance industry (Stock Market to be precise) and they were sort of late adopter of public cloud. They absolutely hated the idea of putting their data on p

Adoption of microservices have changed the way we build software. It's a slim down version of SOA and impacts all areas of SDLC. A successful adoption will require mindset change of how we think, design, test, build, deploy and monitor our products. In this post, I want to discuss Testing methodology which took a 180 degree turn for me. Conventional testing pyramid implies that Unit tests are the most important form of tests. It carries the heaviest weightage. Unit test identifies a small unit of code and test it with combination of parameters. Unit tests are then followed by Service tests. Service tests are the API tests for your service. Usually it consist of a test-suite that includes spinning up the service under test and all its dependencies. A test client can call service API with different inputs and validate that the service is working as expected. At the top of the pyramid are the UI and E2E tests. A typical testing pyramid looks something like: This pyramid makes