Microservices

Thank you folks for raising some great questions. I am consolidating them here for everyone to benefit! How is your experience using Kubernetes?  >> Kubernetes seems very powerful and some experts would say its the modern day kernel for container orchestration. Internally, we use Rancher which I believe has Kuberneter support but I don’t think we are using it yet. We have an entire SRE team that brings fun delivery tools into the pipeline and they are actively looking into it. What are the preferred languages for writing microservices? Any recommended frameworks? >> It really depends on the type of work. If you are writing heavy ETL pipelines then python is pretty awesome! If its a CPU intensive use compiled languages - golang/.net core/java. If its orchestration style or simple get/put/delete DB operation - use nodejs. All the services should be deployed as container so it doesn’t matter which language is used. In terms of frameworks, I have used aiohttp, flask, ex

One of the most important selling point of moving towards microservice architecture is the speed of delivery! Today customers can research products, compare reviews and ultimately switch to better products online with unprecedented ease. To survive in this high customer-focused and fast moving industry, we need our teams to deliver software at an accelerated rate and possibly multiple times in a day. For us over the time, our delivery pipeline has also evolved: During the Enterprise days, the release cycle was 6 weeks long. If you missed anything - wait for another 6 weeks. We used home grown scripts to coordinate all the deployments and overall experience was just awful. During the early days of Cloud, we moved to a daily deployments but these were at the end of the day with significant downtime and required lots of coordination with different teams. Today we have deployments on demand. Teams are deploying multiple time in a day with zero downtime! We love Slack at

Adoption of microservices is not easy and I have had my own share of painful experiences during the initial phase of the transition. In this blog, I will go over some of factors that can be critical to determine the outcome of such transition. Lack of Engineering Culture - What’s an Engineering Culture anyway? Its a culture that practices lean-principles and further enables osmosis style learning for everyone. There is recognition for great work and people are willing to learn from each other. Its a culture where everyone is empowered and feels responsible to participate/evolve/improve all aspects of the SDLC irrespective of their primary role. You can have specialized teams for the different parts but everyones feedback is welcomed. Processes are not followed like a religion but evolved throughout the lifecycle. Adoption of microservices is a steep learning curve for everyone. If an organization doesn’t have the right Engineering mindset, avoid doing microservices. You have ev

Dark-launches and Feature toggles are two great practices to deploy code faster to production and get early feedback. Combined with microservices architecture, it becomes a very powerful tool and once adopted, there is no turning back! You will be thrilled by the speed with which you can build and ship software in a safe manner! In this blog, I will try to explain what these terms means. Dark Launch Dark launch is a practice where you can test/validate your new functionality in production without having to worrying about disturbing the original workflow. This technique is very useful when writing a new version of the functionality or even adding more functionality that can be triggered based of any existing workflow. The steps to achieve it are very simple: Deploy the new functionality in prod.  Incase if it is new version of an existing functionality and you want to test correctness:  clone the request going into v1-logic —> then call the v1-logic —> clone the v1-resul

In my previous blog ( Microservices and Testing - Lessons Learned ), I talked about variation in the testing pyramid and how new flavors of Component Tests (with same good characteristics as those of Unit Tests) have gained momentum and are the primarily source for testing the entire µ-service stack in isolation. In this blog I will talk about how we use the same Component-Test setup to run local Chaos tests!  Microservice architecture is very susceptible to intermittent infrastructure/networking failures which makes Chaos-Engineering a very important aspect for a mature stack. Chaos-Engineering sounds bit chaotic but it is surprisingly easy to do in microservices architecture, specially the local chaos scenarios. To run a full blown Chaos Test, you will need to set aside some dedicated time and bring members from different teams together and run the experiments (Game days!). On the other hand, local chaos scenarios are the ones that you can run locally for your own service stack i

In my previous blog ( Microservices and Testing pyramid ), I talked about the variation in the testing pyramid which is more visible in the microservice stack. In this blog I want to provide some more context as to exactly what is contributing to this variation and share some of the lessons learned in evolving our testing strategy.  A traditional testing pyramid has  Unit Tests at the bottom followed by component tests and finally Integration and UI tests. There are more pictures with further breakdown available over the internet, but this is the crux of it - heavy on Unit Tests then Component Test and finally Integration and UI tests.   Since Unit Tests carry the heavy weightage in the testing pyramid, any significant variation to it has to touch the Unit-Tests and anything that touches Unit-Tests has to have the same good characteristics that we love about them: They are Fast and Stable (here stable means they break only if there is a real failure and not some flakiness in t

In this blog, I want to discuss how adoption of microservices as the mainstream development practice has impacted our Developer Experience and share some of the observations and lessons learned. We have come a long way in terms of evolving our tech stack from being a C#/.net heavy Monolithic Enterprise shop to now lean micro services. Today we have hundreds of microservices written in different stacks with most popular languages being Golang, Python, Nodejs and C# (dot-net core) and everything gets deployed as a container! Looking back, during Enterprise/Monolithic days let’s say I want to work on a story, my developer experience would look something like this: I would come to office in the morning and drink my coffee (most important part of my day!). Download monolithic code + build it + restore DB register + services and all…. basically, trying to get to a point where I have a working system. In monolithic you could spend somewhere between few hours to an entire day from the point wh

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