Ashish Thakur

Ashish Thakur

Recent Posts

Why enterprise applications need a Service Mesh Architecture

Posted by Ashish Thakur on Mar 15, 2019 4:05:00 PM

As enterprises increasingly shift from monolithic to a microservices architecture, IT teams are faced with the problem of effectively orchestrating these microservices. When we have a single application created with a few different containerized services, communication between them can be easily managed. However, enterprise applications with 100s or 1000s of different microservices need a better solution for load balancing, monitoring, traffic routing and security.

Enter the service mesh architecture.

Service Mesh Architecture

A service mesh is an infrastructure layer that manages service-to-service communication, and provides a way to dynamically route, monitor, and secure microservice-based applications.

Previously, the logic governing inter-service communication was coded into each microservice. But that’s not a feasible option when dealing with a large volume of microservices, or scaling applications by adding new services.

The solution is to have proxies that manage the service-to-service communication, running beside each microservice rather than within it. These are also known as ‘sidecar’ proxies and together they form the abstracted mesh architecture that manages the microservices communication.service mesh architecture

Why is this Needed?

The objective with microservices was to build applications as a collection of independent services that can essentially fail without causing system-wide outage. In practice however, most microservice-based applications began operating with direct communication between services. As the application complexity and number of microservices increased, this created greater interdependence between services, thus lowering agility and system resilience.

And hence the complex enterprise applications with a large number of microservices need a service mesh architecture.

Isn't that what APIs did?

Yes, APIs perform a similar function as a service mesh i.e. govern the flow of information. The key difference lies in what kind of communication they govern.

API gateways manage the communication between an application, and others within and outside the enterprise architecture. It provides a single entry point into an application, for requests from all external clients, and handles user-authentication, routing, monitoring and error-handling. It also abstracts the underlying complexity of an application, with its component microservices, from external clients.

A service mesh architecture on the other hand manages the communication between the microservices within an application.

All the proxy sidecars that make up the service mesh are listed in a service registry. Each microservice that wants to request information (client microservice) will have its proxy sidecar look up the registry to find the available proxies associated with the target microservice. It then uses the defined load balancing algorithm to direct its request to the right proxy.

What problems does a service mesh solve?

The service mesh primarily resolves concerns around increasing interdependence that creeps into microservice-based applications as they scale in complexity. Here’s how:

Deploying multiple microservice versions simultaneously

Canary releases, or introducing a new version of a microservice to a select number or type of requests, is a standard way to ease in new feature additions. However, effectively routing requests between old and new versions can be difficult when the logic in coded within each service, because they tend to have interdependencies on other services. Similarly, A/B testing microservice versions also requires dynamic routing capabilities that is best delivered by a service mesh.

The service mesh architecture has the routing rules, and can make the decision to direct source service queries to the right version of the target services. This decoupled communication layer reduces the amount of code written for each microservice, while still better managing inter-service routing logic.

Detailed visibility into inter-service communication

In a complex microservices architecture, it can be difficult to pin-point the exact location of a fault. But once all communication is routed through a service mesh, there is a way to gather logs and performance metrics on all aspects of the microservices. This makes it easier to generate detailed reports and easily trace point of failure.

The logs from the service mesh can also be used to create standardized benchmarks for the application. For example, how long to wait before retrying a service that’s failed. Once these rules are coded into the service mesh, microservices operation becomes optimized as the system doesn’t get overloaded with unnecessary pings to a failed downstream service before the requisite time-out period.

Microservice testing

Testing each microservice in isolation is critical to ensure application resilience. There are also instances where you need to test service behaviour when faults are introduced in downstream services. And that’s difficult and risky to do if we are forcing those faults to actually occur in the services.

The service mesh is the perfect way to simulate these faults in the systems and study the associated response.

Fault Tolerance

Resilience is a key reason why microservices architecture is preferred, and elements like circuit breakers, load balancing, rate-limiting and timeouts are what makes this possible. These rules are usually coded into each microservice , thus increasing complexity in the system, besides being time consuming to create.

Once again, the service mesh can be used to improve fault tolerance by taking these functionalities out of the microservices and adding them to the mesh. These can be implemented via a set of rules that will govern all microservices within the application, without actually cluttering the microservice implementation.

So that was a quick run down on the service mesh architecture and why it’s becoming a crucial infrastructure requirement for enterprise applications. Following blogs will explore service mesh implementation in depth, and evaluate the various tools like Istio, Linkerd and more for service mesh architecture implementation.

Srijan’s teams have expertise in decoupling monolithic systems with elegant single-responsibility microservices, as well as testing, managing and scaling a microservices architecture.

Looking to modernize legacy systems? Drop us a line and our enterprise architecture experts will be in touch.

 

Topics: Microservices, Architecture, Enterprises

Pushing limits: The Tuffman Ultra experience

Posted by Ashish Thakur on May 7, 2018 1:06:00 PM

Tuffman India organized the Ultra marathon - a 50 km run through some of the most scenic landscapes of Manali. Tuffman races and events are one of a kind, where they make you learn about yourself and help you discover your real tuff (tough) soul. And they had done a great job by organizing this event. 

Having done a few marathons before, I knew that building my stamina was key. And so I went through an incredible 16-week training schedule. I trained hard, and maintained my usual diet that I follow for long runs. The last couple of weeks of training was not really up to my expectations, as I would be in a different city for some work. Despite that, I tried to train and ran a couple of miles in Bristol, Delhi, Chandigarh, and Mumbai. One week before the race I was in Manali and was training there, as running in mountains is a different skill. Few easy runs before the event in Manali made me confident.

Ashish Tuffman Experience

Training aside, since this was my first ever ultra marathon, there was a certain amount of apprehension in my mind. But the fact that others from Srijan’s Goa office were training beside me, and that the marathon was happening in my home ground Manali, made me more confident. 

The day of the marathon dawned bright and clear. The race course swept by cool breeze, dotted with cool shacks, and provided me a reviving and zealous escapade altogether. My fellow runners in this ultra race were from the navy, army, and people who had finished tough marathons like Comrades and Run the Rann. It was a fun environment and it was great to share the track with several experienced runners.

It was an amazing run at an altitude of 6700 ft. The track was divided into two loops: 14 km + 36 km. The 14 km loop was fairly easy and was on a flat road with some elevation gain. The 36 km loop was quite a challenging run with steep slopes of more than 30 degrees. The last 5 km was a strategic run where I ran for a while with all my energy and finished my first 50 km with timings of 6 hours 52 minutes, and finished second in 50 km category. 

Ashish Thakur

The route was long, and it was hard but it was worth it.

After several marathons, running has become my meditation, where I go into this trance state and completely forget about the distance. And now, I am preparing myself for another run.  My next running schedule is Malnad Ultra: 80k, ParadiseTrails Goa: 101 km, and Run the Rann: 101 km. Training for these races has already started and I am eagerly waiting for Malnad Ultra. It would be sheer fun running in a coffee estate. 

In case folks in Srijan are reading this, this is my running wishlist. Now you know what to gift me! :) 

Topics: Community

Retrospective on Drupal Contributions

Posted by Ashish Thakur on Jul 4, 2015 12:12:00 PM

One fine day I landed on the marketplace page of Srijan at drupal.org and came across a new section  *Contributed 42 issues in last three months*. I was glad that the much awaited feature of giving credits to an organization is finally live!

In the past we have been using stats from http://drupalcores.com/companies.html to check how Srijan has been performing in terms of Drupal core contributions. In the last eight months we have climbed from 86th position to 25th position as of 1st July, 2015.

Our journey to the 25th position was exciting, and it was a collective effort of Srijan developers who were focused to give back to the Drupal community. And it involved some great mentorship by Ravindra, Manjit and myself. In the last quarter we successfully organized four code sprints at Srijan’s office, and one of these was an overnight Hackathon.

The July to September quarter would be more exciting. It will be exciting because in the next eight months, two DrupalCons are scheduled - DrupalCon Barcelona and DrupalCon Asia. DrupalCon Asia will be the first in Asia and the Drupal community in India is leaving no stone unturned to make it successful. Every other week a code sprint, Drupal training or camps are being organized. At Srijan we are starting the quarter with a Drupal Training in Ahmedabad which is one of the first Drupal events in the region. This will be followed by Drupal Training in Chandigarh. In Delhi region, we plan to conduct two code sprints per month and we welcome the Drupal community here to come and participate in these events. 

However, there are always some challenges. We struggled to find issues for new developers to work with. It is also a challenge to avoid burnout and maintain the enthusiasm for contributions. We have worked hard on these roadblocks and come out with some other interesting activities to keep the enthusiasm alive. We have also found novice issues for new developers to work with.

One of the exciting things that has happened in the last three months is that lots of QA folks have started helping in contributions. This hadn’t happened before and their help in manual and UI testing is tremendous. Thanks guys, for turning up for the code sprints and meetups. We would love to see the same energy in all forthcoming sessions as well. And as we had promised that the one with max commit mentions or contributions in the last quarter would travel to DrupalCon Barcelona. So this time it is Manjit who by the end of Q2 had the maximum commits (23 commit mentions). Good things happen when you are an avid Drupaler! :)

Topics: Drupal, Open Source Contributions

At Drupal Camp London 2015

Posted by Ashish Thakur on Mar 4, 2015 1:31:00 PM

Jet lagged, I landed at Heathrow Airport to participate in Drupal Camp London 2015. I was excited to meet the Drupal community in Europe and present my session on ‘Drupal 8 for site builders’.

The 2015 edition of Drupal Camp London was a three-day event held from 27 February to 1 March, and more than 500 people attended the camp. It was held at City University London, Northampton Square and Srijan was one of the Gold Sponsors of the camp. Rahul Dewan, Arijit Dutta and I were representing Srijan, and in fact, India at this event. I had to leave immediately after the camp but Arijit stayed back for QCONand has promised to share his learnings in the event via a session and a blog perhaps.

Here’s what happened at Drupal Camp London 2015:

Day 1

The first day, called the CXO Day, was focused more on business. Though I am not a C-level executive (I hope to be one day!), I attended the CXO Day. It was a great experience listening to the business leaders on topics ranging from personal development, technology to Drupal Association, Drupal ecosystem in London in public sector, agile and fixed cost projects.

Here a unique thing was 'un-conference' on topics which keep CXOs up at night. These topics were suggested by the participants. They were divided into groups and an informal discussion was held in each group, with one volunteer collating the points and presenting it to rest of the groups at the end of the discussion. Some of the topics were: Drupal for products, Drupal Association in EU, Agile and fixed priced contracts, Agile project management, Sales & marketing, Hiring Drupal talent.

The day ended with networking. I met folks from Amazee Labs, CTI Digital and other community members. Then, someone from the hospitality team convinced me to have another glass of wine which is something I would also like right now!

Day 2

We headed to the Camp armed with Srijan banners and brochures. The second day was kicked off with a keynote by Dr. Sue Black (@Dr_Black). The keynote can be found here.

We showcased Sarus at our booth which I think got lots of folks excited. Sarus is open sourced, so please feel free to use it for your blogs and publishing sites. A session by @mortendk on Twig and a session on rules by Josef Dabernig were insightful. When I was not attending the sessions, I was busy networking with folks at our booth and showcasing our work. It was a busy day which ended with a social night where we joined the Drupal community for beers. Cheers! 

Day 3

The day’s keynote was by Robert Douglass and he spoke about platform.sh. Immediately after the keynote, I had to conduct my session on Drupal 8 for site builders. The session went well except for some demo hiccups (looks like I forgot to pray to the Demo Gods before the session!).

The day ended with the code sprint where we met alexpott, swentel, vijaycs85 and other folks from the community. Arijit and I submitted a total of eight patches, four of them got RTBCed during the sprint and some got rejected. Overall, it was a great learning experience meeting folks whom we just knew from drupal.org or IRC. 

That was Drupal Camp London. Time to get back to some of the patches which got rejected!

Topics: Drupal, Community

Discussion

Write to us

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms Of Service apply. By submitting this form, you agree to our Privacy Policy.

See how our uniquely collaborative work style, can help you redesign your business.

Contact us