<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>microservice on Dhaval Shah</title><link>https://www.dhaval-shah.com/tags/microservice/</link><description>Recent content in microservice on Dhaval Shah</description><generator>Hugo -- gohugo.io</generator><lastBuildDate>Tue, 07 May 2024 00:00:50 +0000</lastBuildDate><atom:link href="https://www.dhaval-shah.com/tags/microservice/index.xml" rel="self" type="application/rss+xml"/><item><title>Migrating Spring Boot application from 2.x to 3.x</title><link>https://www.dhaval-shah.com/spring-boot-migration-from-2.x-to-3.x/</link><pubDate>Tue, 07 May 2024 00:00:50 +0000</pubDate><guid>https://www.dhaval-shah.com/spring-boot-migration-from-2.x-to-3.x/</guid><description>Background Lot of my pet projects have been built using Spring Boot 2.x version. Same might be applicable for all the enterprises and organizations who have been building Microservices based applications for their products / services using Spring Boot. During last year, Spring community made a major version upgrade and thereafter released Spring Boot 3.2 version with bunch of new features.
First thing that comes to our mind is Why should I migrate my application from 2.</description></item><item><title>Refactoring from imperative to reactive implementation</title><link>https://www.dhaval-shah.com/refactoring-from-imperative-to-reactive-implementation/</link><pubDate>Mon, 27 Jan 2020 21:06:28 +0000</pubDate><guid>https://www.dhaval-shah.com/refactoring-from-imperative-to-reactive-implementation/</guid><description>Background As software industry is embracing the new Microservice Architecture paradigm, myriad applications have been built with Spring Boot framework. By the time organizations have got its early versions of microservice applications in production, industry has found out newer and better avenues for further optimizing microservices, so that systems can be more robust, resilient and responsive a.k.a Reactive Systems (as per Reactive Manifesto ). Thanks to Spring Reactor and Spring Webflux which can help us in building reactive systems using Spring framework.</description></item><item><title>Chaos Engineering – Demonstration with working example (Part-2)</title><link>https://www.dhaval-shah.com/chaos-engineering-demonstration-with-working-example/</link><pubDate>Fri, 02 Aug 2019 17:21:13 +0000</pubDate><guid>https://www.dhaval-shah.com/chaos-engineering-demonstration-with-working-example/</guid><description>Background From first part of blog we gathered understanding about basics of Chaos Engineering. Now we will further deep dive to understand how to perform Chaos Engineering with a working example - which to me is going to be quite interesting. First lets start with understanding basics of working example which will be used to demonstrate following-
How to perform chaos engineering within an application How to monitor the behavior of the system What to monitor whilst executing experiments on our system Bird's eye view of demo example</description></item><item><title>Chaos Engineering – A quick primer</title><link>https://www.dhaval-shah.com/chaos-engineering-a-quick-primer/</link><pubDate>Sun, 30 Jun 2019 18:13:30 +0000</pubDate><guid>https://www.dhaval-shah.com/chaos-engineering-a-quick-primer/</guid><description>Human body is vulnerable to lot of diseases. So in order to protect human beings from diseases vaccines have been invented. Vaccines mainly work due to process called 'Hormesis', by which system or organism adapts to harm in order to become stronger. Just as our body is susceptible to diseases and germs, so do our systems in software world. Hence vaccines and vaccination can be considered as an apt analogy for understanding Chaos Engineering.</description></item><item><title>Microservices and Consumer Driven Contract testing using Pact</title><link>https://www.dhaval-shah.com/microservices-and-consumer-driven-contract-testing-using-pact/</link><pubDate>Mon, 10 Jul 2017 20:37:52 +0000</pubDate><guid>https://www.dhaval-shah.com/microservices-and-consumer-driven-contract-testing-using-pact/</guid><description>Background As per the current trends, Microservice Architecture has become a common paradigm using which enterprise applications are built. With this paradigm shift, an application is going to have myriad set of independent and autonomous (micro)services. So how does a developer do testing within Microservice Architecture? Answer is very obvious -
Create integration tests that invokes microservice under test which will internally call dependent microservices Get all the services under test up and running Start executing integration test which invokes microservice under test With this approach, the entire developer level integration testing will have following disadvantages -</description></item><item><title>Unraveling the magic behind Spring Boot</title><link>https://www.dhaval-shah.com/unraveling-the-magic-behind-spring-boot/</link><pubDate>Sun, 14 May 2017 18:30:00 +0000</pubDate><guid>https://www.dhaval-shah.com/unraveling-the-magic-behind-spring-boot/</guid><description>Considering the extensive usage of Spring Boot for building Cloud Native Architecture, I embarked on the journey of utilizing it in my reference Cloud Native application. When I ran my first application I was literally flabbergasted with the magic Spring Boot does under the hood, using which it camouflages the complexity and challenges of building enterprise applications. In order to understand capabilities of Spring Boot and thereby have its justifiable usage along with its troubleshooting skills I felt a dire need of demystifying the magic behind it!</description></item><item><title>Understanding Cloud Native Architecture with an example</title><link>https://www.dhaval-shah.com/understanding-cloud-native-architecture-with-an-example/</link><pubDate>Thu, 16 Mar 2017 05:20:05 +0000</pubDate><guid>https://www.dhaval-shah.com/understanding-cloud-native-architecture-with-an-example/</guid><description>Whenever the buzz word 'Cloud Native Architecture' gets to our ears, first thing that comes to our mind is - It sounds too jazzy and latest and would have something to do with technology since it has a word called 'Architecture' within it :). Because of this it creates a perception in the minds of lot of people that 'Cloud Native Architecture' is just about TECHNOLOGY. Unfortunately, this is one of the most common misconception that prevails currently in the industry.</description></item></channel></rss>