Techila Shots

A Brief Guide to ViewGrip.net: Features and Usage

2026-05-01T01:21:00.002+05:30

1. Introduction to ViewGrip.net

ViewGrip.net is an online platform designed to help users increase engagement on social media. It mainly focuses on boosting metrics like views, likes, followers, and shares across different platforms.

People use it to improve their online presence, especially for platforms like YouTube, Instagram, and others.

2. What ViewGrip.net Offers

2.1 Social Media Growth Services

ViewGrip provides services such as:

These services are useful for content creators who want more visibility.

2.2 Multiple Platform Support

The platform usually supports:

YouTube
Instagram
Facebook
TikTok

This makes it convenient if you manage multiple social accounts.

2.3 Easy-to-Use Interface

The website is simple and beginner-friendly. Even if you are new, you can:

Choose a service
Enter your link
Submit your request

No technical skills are needed.

3. How to Use ViewGrip.net

3.1 Step-by-Step Process

Visit the website
Select the service you want (e.g., YouTube views)
Paste your video or profile link
Choose the quantity
Submit the request

Some services may require login or payment, while others might be free.

4. Key Features

4.1 Fast Delivery

Orders are usually processed quickly. This helps users see results in a short time.

4.2 Automated System

The platform works automatically, meaning once you submit your request, the system handles everything.

4.3 Free and Paid Options

Some features may be free, while others require payment for better results.

5. Benefits of Using ViewGrip.net

5.1 Saves Time

Growing social media organically can take a long time. This platform speeds up the process.

5.2 Improves Visibility

Higher views and likes can make your content look more popular, attracting real users.

5.3 Useful for Beginners

If you're just starting, it can give your content an initial push.

6. Important Considerations

6.1 Platform Policies

Some social media platforms do not allow artificial growth. Using such services may carry risks.

6.2 Quality of Engagement

Not all engagement may come from real users, so it may not always lead to meaningful interaction.

6.3 Use Responsibly

It’s best to combine these services with genuine content creation for long-term success.

7. Conclusion

ViewGrip.net is a simple tool for boosting social media engagement quickly. It offers various services, is easy to use, and can help improve visibility. However, users should be aware of the risks and use it wisely along with organic growth strategies.

My GitHub Repo #30 : Obelix (MSA Reference Architecture)

2024-10-10T02:33:00.012+05:30

[Obelix - MSA Reference Implementation]
MIT License, Copyright (c) 2018-19, Sumith Kumar Puri
https://github.com/sumithpuri

GitHub Link : https://rebrand.ly/skp-gitrepo-30

Project Codename	Obelix - Microservices Reference Implementation
Blog Post URL	http://www.techilashots.in/2022/07/obelix-microservices-reference.html
Topics/Areas	-
Package Prefix	com.obelix.demo
GitHub URL	https://github.com/sumithpuri/skp-msa-ri-obelix
Contact E-Mail	code@sumithpuri.xyz
Contact Number	+91 9591497974 (WhatsApp, Viber, Telegram)
Historical	✅ Started this Movement of 1000s of Lines of Java / J2EE* Code to GitHub ✅ Was a Senior Software Architect (Java/J2EE) in Manila, 2018 (At Start) ✅ Named this Initial Code Journey as [ Manila Code Marathon - 2018* ] ✅ Code Is Non-Proprietary and Non-Copyright from my Work Experience. ✅ Was Back to Bangalore, Named as [ Bangalore Code Nights - 2019. ] ✅ Added More Code under [ -20 Days of Code in Benglauru- ] in 2020 ✅ Celebration of Java/Java EE Code as Java Turned 25 in the Year ~ 2020! ✅ Continued this Coding Mania under : [ 20 Days of Code in Dec 2022 ]

[Topics/Areas] Spring Boot, Spring Data, Spring Cloud, Spring Security, Spring Feign, Spring Ribbon, Netflix OSS, API Gatway, Circuit Breaker, Config Server, Discovery Server, Load Balancer, Hystrix, Turbine, Observability, Health Check, Spring Design & Data Patterns.

My GitHub Repo #29 : Spring Boot and Docker

2024-10-10T01:54:00.006+05:30

Code Samples for [Spring Boot and Docker]
MIT License, Copyright (c) 2018-19, Sumith Kumar Puri
https://github.com/sumithpuri

GitHub Link : https://rebrand.ly/skp-gitrepo-29

Project Codename	Spring Boot and Docker
Blog Post URL	https://foojay.io/today/starting-docker-desktop-with-spring-boot/
Areas/Topics	Spring Boot, Spring Boot & REST API, Docker, Docker Desktop, Spring Boot on Docker
Package Prefix	com.springboot.docker
GitHub URL	https://github.com/sumithpuri/skp-spring-boot-docker-desktop
Contact E-Mail	code@sumithpuri.xyz
Contact Number	+91 9591497974 (WhatsApp, Viber, Telegram)
Historical	✅ Started this Movement of 1000s of Lines of Java / J2EE* Code to GitHub ✅ Was a Senior Software Architect (Java/J2EE) in Manila, 2018 (At Start) ✅ Named this Initial Code Journey as [ Manila Code Marathon - 2018* ] ✅ Code Is Non-Proprietary and Non-Copyright from my Work Experience. ✅ Was Back to Bangalore, Named as [ Bangalore Code Nights - 2019. ] ✅ Added More Code under [ -20 Days of Code in Benglauru- ] in 2020 ✅ Celebration of Java/Java EE Code as Java Turned 25 in the Year ~ 2020! ✅ Continued this Coding Mania under : [ 20 Days of Code in Dec 2022 ]

My GitHub Repo #28 : Spring Boot REST API

2024-10-10T00:56:00.006+05:30

Code Samples for [Spring Boot - REST API]
MIT License, Copyright (c) 2018-19, Sumith Kumar Puri
https://github.com/sumithpuri

GitHub Link : https://rebrand.ly/skp-gitrepo-28

Project Codename	Spring Boot - REST API
Blog Post URL	---
Topics/Areas	Spring Boot, Spring Boot & REST API
Package Prefix	com.example.demo
GitHub URL	https://github.com/sumithpuri/skp-spring-boot-rest
Contact E-Mail	code@sumithpuri.xyz
Contact Number	+91 9591497974 (WhatsApp, Viber, Telegram)
Historical	✅ Started this Movement of 1000s of Lines of Java / J2EE* Code to GitHub ✅ Was a Senior Software Architect (Java/J2EE) in Manila, 2018 (At Start) ✅ Named this Initial Code Journey as [ Manila Code Marathon - 2018* ] ✅ Code Is Non-Proprietary and Non-Copyright from my Work Experience. ✅ Was Back to Bangalore, Named as [ Bangalore Code Nights - 2019. ] ✅ Added More Code under [ -20 Days of Code in Benglauru- ] in 2020 ✅ Celebration of Java/Java EE Code as Java Turned 25 in the Year ~ 2020! ✅ Continued this Coding Mania under : [ 20 Days of Code in Dec 2022 ]

My GitHub Repo #27 : Spring Boot Shutdown

2024-10-07T08:14:00.008+05:30

Code Samples for [Spring Boot - Graceful Shutdown]
MIT License, Copyright (c) 2018-19, Sumith Kumar Puri
https://github.com/sumithpuri

GitHub Link : https://rebrand.ly/skp-gitrepo-27

Project Codename	Spring Boot Shutdown
Blog Post URL	https://foojay.io/today/clean-shutdown-of-spring-boot-applications
Topics/Areas	Terminate Application and Kill Process and Kill Process Using TCPView, Actuator, Close SpringBootApplicationContext, SpringApplication.exit()
Package Prefix	com.springboot.shutdown
GitHub URL	https://github.com/sumithpuri/skp-spring-boot-shutdown
Contact E-Mail	code@sumithpuri.xyz
Contact Number	+91 9591497974 (WhatsApp, Viber, Telegram)
Historical	✅ Started this Movement of 1000s of Lines of Java / J2EE* Code to GitHub ✅ Was a Senior Software Architect (Java/J2EE) in Manila, 2018 (At Start) ✅ Named this Initial Code Journey as [ Manila Code Marathon - 2018* ] ✅ Code Is Non-Proprietary and Non-Copyright from my Work Experience. ✅ Was Back to Bangalore, Named as [ Bangalore Code Nights - 2019. ] ✅ Added More Code under [ -20 Days of Code in Benglauru- ] in 2020 ✅ Celebration of Java/Java EE Code as Java Turned 25 in the Year ~ 2020! ✅ Continued this Coding Mania under : [ 20 Days of Code in Dec 2022 ]

My GitHub Repo #26 : HongKong

2024-10-03T08:43:00.007+05:30

Code Samples for [Assorted Algorithms & Data Structures]
MIT License, Copyright (c) 2018-19, Sumith Kumar Puri
https://github.com/sumithpuri

GitHub Link : https://rebrand.ly/skp-gitrepo-26

[ C ] Graph Search / Traversal Algorithms (DFS - Depth First Search)
[ C ] Graph Search / Traversal Algorithms (BFS – Breadth First Search)
[C++] Binary Search Tree (BST) Traversal – Inorder Tree Traversal
[C++] Binary Search Tree (BST) Traversal – Postorder Tree Traversal
[C++] Binary Search Tree (BST) Traversal – Preorder Tree Traversal
[Java] Sorting Algorithms – Quick Sort
[Java] Sorting Algorithms – Merge Sort
[Java] Sorting Algorithms – Heap Sort
[Java] Algorithms & Data Structures – Reverse a Linked List
[Java] Algorithms & Data Structures – Dijkstra’s Algorithm
[Java] Algorithms & Data Structures – Circular Linked List

Project Codename	HongKong
Blog Post URL	[Multiple]
Blog Short URL	[ C ] Graph Search / Traversal Algorithms (DFS - Depth First Search) [ C ] Graph Search / Traversal Algorithms (BFS – Breadth First Search) [C++] Binary Search Tree (BST) Traversal – Inorder Tree Traversal [C++] Binary Search Tree (BST) Traversal – Postorder Tree Traversal [C++] Binary Search Tree (BST) Traversal – Preorder Tree Traversal [Java] Sorting Algorithms – Quick Sort [Java] Sorting Algorithms – Merge Sort [Java] Sorting Algorithms – Heap Sort [Java] Algorithms & Data Structures – Reverse a Linked List [Java] Algorithms & Data Structures – Dijkstra’s Algorithm [Java] Algorithms & Data Structures – Circular Linked List
Package Prefix	me.sumithpuri.github.hongkong
GitHub URL	https://github.com/sumithpuri/skp-winter-code-n-ights-hongkong
Contact E-Mail	code@sumithpuri.xyz
Contact Number	+91 9591497974 (WhatsApp, Viber, Telegram)
Historical	✅ Started this Movement of 1000s of Lines of Java / J2EE* Code to GitHub ✅ Was a Senior Software Architect (Java/J2EE) in Manila, 2018 (At Start) ✅ Named this Initial Code Journey as [ Manila Code Marathon - 2018* ] ✅ Code Is Non-Proprietary and Non-Copyright from my Work Experience. ✅ Was Back to Bangalore, Named as [ Bangalore Code Nights - 2019. ] ✅ Added More Code under [ -20 Days of Code in Benglauru- ] in 2020 ✅ Celebration of Java/Java EE Code as Java Turned 25 in the Year ~ 2020! ✅ Continued this Coding Mania under : [ 20 Days of Code in Dec 2022 ]

SKP's Microservices #04 - Failures, Pitfalls & Disadvantages of Microservices

2024-09-14T10:00:00.004+05:30

Intro to SKP's Microservices Masterclass Series

SKP's Microservices Masterclass is a Series of Articles on Microservices Architecture (MSA) - Starting with the Needs and Motivations of Microservices, Moving to the Shortcomings of Monolithic Architecture and Also Covering Microservices Design Patterns, Pitfalls of Microservices, Major Microservices Infrastructure Components - Description, Evaluation and Code Samples, Containers, Native Microservices, Cloud Platforms, Messaging Layers, Security and Logging. We will Provide the Readers with Obelix, A Microservices Architecture Reference Implementation! You May Use this as the Starting Point for your Microservices Architecture. You may Also Directly Use this as a Reference Implementation for your Microservices Strategy and/or as Code to Learn and Implement the Microservices Architecture for your Organization.

FIG. 1 : INDICATIVE COMPLEXITY OF MICROSERVICES ARCHITECTURE IN THE ENTERPRISE

Introduction to Microservices Adoption in Real World

Microservices Adoption is almost becoming the Normal in almost all Software Product and IT Services Organizations. Hereby, I am taking this Opportunity to make you Aware of the Real-World Issues (Case Studies) that are faced by Organizations (Small, Mid, Large) of all Sizes in Migrating or Adopting Microservices. Since Learning from Other's Mistakes and Knowing the Pitfalls Upfront help us Prepare and Plan Better - This Article will be Helpful for those Planning a Shift to the Microservices Strategy Organization-Wide or simply Making a Move from Monolithic to Microservices Architecture.

It is Mandatory that all of you Skim Through The Below Articles (Titles) and then Read a Few Articles that you find are closest to your Job Function. In this Article, I am Providing only the Brief Explanation of the Main Challenges of Adopting Microservices. Also, You may use this as a Ready Reference Index for Articles Published on the Internet to Further Your Knowledge fo the Pitfalls of Adopting Microservices.

Adopting Microservices has Been a Great Challenge for All – Netflix, Amazon, Uber and even IT Service Companies have had their share of Challenges in Microservices Migration/Adoption – Thoughtworks, Cognizant, IBM, Infosys, Xebia. Few Companies have Reverted Back to Monolith after their Microservices Strategy / Implementation Failed or Did Not Yield the Desired Gains.

[So, The Idea is that You Do Not Make the Same Mistakes, Learn from the Below and Try to Get it Right the First Time – Hence, We Need to Invest Time in Quality Research and Development to build the Initial and Robust Architectural Pieces. Also, To Create a Meaningful and a More Realistic Plan for Organization-Wide Microservices Adoption in a Software Product Company. These are also valid for Adoption / Evangelizing to your Customers in an IT Services Organization.]

Practical Challenges in Adoption of Microservices

Overhead
The Setup of Microservices Requires More Efforts as there a Lot of Infrastructural Architectural Pieces as part of a Complete Microservices Architecture. For Example - API Gateway, Circuit Breaker, Discovery Server, Config Server, Health Monitoring, Vault Service, Token Service, Logging & Auditing - These are Just a Few of the Initial Infrastructural Services Required to Correctly Implement a Complete Microservices Architecture in the Enterprise.
High Skill
There is a High Skill Level Require Especially in Terms of Experienced Senior Architects, DevOps and Developers who can Now Understand the Change in Development Paradigm. Also, This May Either Increase the Development Time or Development Costs or Both.
Complexity
One of The Most Important Disadvantages of Microservices is the Complexity Involved. Even Though the Point is Captured in the Above 2 Points - It Still Requires a Mention on its Own. The Interplay of the Plethora of Infrastructural Services along with the Actual Application Microservices may Create Unending Cycle(s) of Complexity.
Redundancy
During Development, the Architects and Lead Engineers may Need to Keep a Watch on Making Sure that there is No Duplication of Code, Configuration or any other Effort that may Already have been Developed by Another Team. This Starts Becoming a Greater Concern when there are Geographically Distributed Teams and Focussing Entirely on their Own Set of Business or Product Deliverables. Though some very Trivial Code Duplication may be Inevitable as far as Possible - Discipline will be Required to Isolate and Group Common Functionality or Code Together Correctly.
Data Duplication
One of the Greatest Challenge is Data Duplication. Most Inexperienced Architects and Engineers may end up in Such Situations. It is because the Thought that was required to Build Monolith Data Access and Creation cannot Now be used for Microservices. The Mechanism to Maintain Data Integrity and Data Consistency in a Product to Make Sure that There Exits a Correct 'Single Version of Truth' Needs to be Planned, Architected and Infused into the Design.
Communication
The Communication Between External World and Microservices or within Microservices may Fail. This could be Due to Multiple Reasons Including Network Failure and Service Unavailability. In any Case, The Communication Between Microservices is Critical and is Tough to Setup and Maintain. It also Requires Constant Monitoring of Health and Performance of Each of the Microservices. Partial Failures is actually an Advantage of Microservices - But Still the Monitoring, Failure Detection, Failure Handling and Simply the Internal/External Communication can be Quite an Overhead in the Implementation of Microservices.
Maintenance
So, Once the Initial Part is Over - Even If the Microservices Strategy and Implementation Turns out to be a Success - It still Means a Heavy Hit on the Pocket for Maintenance. Even though all of the Current Generation Organizations Rely on an External Cloud Provider, It Still Means More Expenditure on Hardware, 'Software', Cloud, DevOps Engineers. Also, the Total Cost of Ownership of Such an Infrastructural Masterpiece is Only Bound to Increase as More Abstractions are Added Over Time - Also, The Maintenance Itself could be a Complicated Process.

Articles from Online Developer Magazines (By Topic)

Challenges of Moving from Monolithic to Microservices

Top 3 Challenges of Adopting Microservices as Part of Your Cloud Migration	https://devops.com/top-3-challenges-of-adopting-microservices-as-part-of-your-cloud-migration/
From Monolith to Microservices: Horror Stories and Best Practices	https://techbeacon.com/app-dev-testing/monolith-microservices-horror-stories-best-practices
Advantages and Disadvantages of Microservices Architecture	https://cloudacademy.com/blog/microservices-architecture-challenge-advantage-drawback/
Fearless Monolith to Microservices Migration – A Guided Journey	https://www.dynatrace.com/news/blog/fearless-monolith-to-microservices-migration-a-guided-journey/

Failure and Pitfalls of the Microservices Strategy

Experiences from Failing with Microservices	https://www.infoq.com/news/2014/08/failing-microservices/
How To Succeed at Failure with Microservices	https://thenewstack.io/succeed-failure-microservices/
How to Condemn Your Microservices Architecture to Fail	https://blog.couchbase.com/condemn-microservices-architecture-fail-even-start/
Your Microservice Architecture Will Collapse	https://dzone.com/articles/your-microservice-architecture-will-collapse

Learn from Other's Mistakes in Microservices

5 Big Microservices Pitfalls to Avoid During Migration	https://searchapparchitecture.techtarget.com/tip/5-big-microservices-pitfalls-to-avoid-during-migration
Tech Talks With Tom Smith: Issues in Migrating to Microservices	https://dzone.com/articles/issues-in-migrating-to-microservices
11 Reasons Why You Are Going To Fail With Microservices	https://medium.com/xebia-engineering/11-reasons-why-you-are-going-to-fail-with-microservices-29b93876268b
Failing at Microservices - Please Avoid Our Mistakes!	https://rclayton.silvrback.com/failing-at-microservices

Planning a Microservices Adoption in the Enterprise

Pitfalls & Challenges Faced During a Microservices Architecture Implementation	https://www.cognizant.com/whitepapers/pitfalls-and-challenges-faced-during-a-microservices-architecture-implementation-codex5066.pdf
4 Challenges You Need to Address with Microservices Adoption	https://www.appdynamics.com/blog/product/4-challenges-you-need-to-address-with-microservices-adoption/
Challenges when Implementing Microservices	https://developer.ibm.com/technologies/microservices/articles/challenges-and-benefits-of-the-microservice-architectural-style-part-1/
How to Plan a Microservices Migration	https://medium.com/@philsarin/how-to-plan-a-microservices-migration-9b4ac50dfa95
Fearless Monolith to Microservices Migration – A Guided Journey	https://www.dynatrace.com/news/blog/fearless-monolith-to-microservices-migration-a-guided-journey/

Real-World Case Studies of Microservices Adoption

Why and How Netflix, Amazon, and Uber Migrated to Microservices: Learn from Their Experience	https://www.hys-enterprise.com/blog/why-and-how-netflix-amazon-and-uber-migrated-to-microservices-learn-from-their-experience/
Explore UBER’s Microservice Architecture	https://medium.com/edureka/microservice-architecture-5e7f056b90f1
Why Microservices Fail? — Xebia Blog	https://xebia.com/blog/why-microservices-fail/

Is it the Death of Microservices - Already, In 2021 ?

Microservices to Not Reach Adopt Ring in ThoughtWorks Technology Radar	https://www.infoq.com/news/2018/06/microservices-adopt-radar/
The Death of Microservice Madness in 2018	https://dwmkerr.com/the-death-of-microservice-madness-in-2018/
Goodbye Microservices: From 100s of Problem Children to 1 Superstar	https://segment.com/blog/goodbye-microservices/
Unraveling Microservices: Higher Agility or Hype?	https://www.infosys.com/digital/insights/documents/higher-agility-hype.pdf

Conclusion and 'Gyan' for Real-World Adoption

Let us Take a Look a Uber's Microservices Dependency Graph (Source : Online Presentation by an Uber Engineer - All Rights Reserved by Uber - Solely Used to Demostrate Complexity). It Seems like an Outer Space Image from a Hubble Telescope! :-)

FIG. 2 : REAL-WORLD MICROSERVICES DEPENDENCY GRAPH FROM UBER ENGINEERING

Idea is not to cause Paranoia or Pessimism – But to Better Estimate and Plan for Success. The Microservices Animal isn’t like our Regular Monolithic Technology Evaluations – Only Working Together in a Focussed Way, We can Tame it Decisively. Else, We may end up in Being Unable to Achieve Desired Functionality, Cycles of Rework, Poor Architecture, High Data Redundancy, Questionable Data Integrity, Performance Worser than Monolith among Other Issues – We may even have to Revert Back / Miserably Fail.

Individually, I Have Worked in 3 Organizations where Microservices Adoption or Migration was Going On – As Far as I Know, the First Project was Shelved after about 4-6 Months – In The Second One, 'Real Microservices' Did Not Go Ahead even after about 1.5 Years (Including the Time of 6 Months After My Joining) – It was Far from a Microservices Readiness or Certification. In the 3rd Organization, where Majority or Meat of the Experience for this Article comes from - I was in charge of Technically Leading the Microservices Strategy, in the role of a Principal Architect. Until my Tenure in the Organization, We had Upfront Identified Major Issues in Architecture by Group Review Processes. We had also Improved Upon Existing Implementation by Iterating through Cycles of Infrastructure Architecture, DevOps Architecture, Technology Evaluations, Creating Reference Implementations, Deciding Release Branches, Regular Architecture Demos and Planning for Architecture Validation and Deciding to Roll out the Reference Architecture Implementation for General Developer Usage in Product Development.

Kindly Take Time to Internalize these Thoughts as Microservices Architecture is the Current Big Bet for Software Product Organizations and IT Services Organizations in 2021. It will continue to be the same for a Few Years from Now! Organizations are going to Spend a Maximum Part of their IT/R&D Budget in Adopting Microservices - So, Upfront Identification by Stakeholders will give the Bang for the Buck!

So, Here's Wishing you a Lot of Skill, Focus, Pragmatism, Understanding, Reasoning and Continued Experience to get the Best Out of Microservices for your Organization and Needs!

[Disclaimer : Please Note that the Article Content in the Links Provided in this Article is the Sole Property of the Respective Authors and their Publishers.]

SKP's Microservices #03 - Moving from Monolith to Microservices

2024-09-08T10:00:00.002+05:30

Intro to SKP's Microservices Masterclass Series

SKP's Microservices Masterclass is a Series of Articles on Microservices Architecture (MSA) - Starting with the Needs and Motivations of Microservices, Moving to the Shortcomings of Monolithic Architecture and Also Covering Microservices Design Patterns, Pitfalls of Microservices, Major Microservices Infrastructure Components - Description, Evaluation and Code Samples, Containers, Native Microservices, Cloud Platforms, Messaging Layers, Security and Logging. We will Provide the Readers with Obelix, A Microservices Architecture Reference Implementation! You May St Use this as the Starting Point for your Microservices Architecture. You may Also Directly Use this as a Reference Implementation for your Microservices Strategy and/or as Code to Learn and Implement the Microservices Architecture for your Organization.

Microservices Architecture : Moving from Monolithic to Microservices

Moving from Monolithic to Microservices

This article tries to provide a sequence of steps to move from monolithic to microservices architecture. An architect or technical stakeholder can use this as a guideline reference for their microservices strategy planning. It tries to cover the functions of research & development, product/application development, devops, testing, engineering management (agile, demos) and product management (demos, prioritization). We also try to cover the code branching strategy briefly. This articles revisits (from earlier articles in this series) the challenges of moving from monolithic to microservices. At the end, the article will provide a series of checklists (excel) to be used in your application/product development.

Remember that this article may also help your organization for a go/no-go decision on microservices. As a technical decision maker, you should be able to bold enough to make a decision against microservices - if you have ascertained that after your research & survey. It is not mandatory that every piece of software be written using microservices! Also, be open to consider hybrid, other software architecture forms or find in place solutions to the problems faced by your application.

Understanding the Existing Monolithic Architecture

SKP's Microservices Masterclass - the most common software architecture that one can safely say has been in existence ever since software development started - it is the monolithic architecture. There have been many forms of monolith over the ages. A single block of software (such as desktop), distributed architectures such as 2-tier, 3-tier, n-tier are all examples of monolithic architecture. For the sake of this article, we will use the most common and standardized example of a 3-tier monolithic architecture. Most enterprise systems prior to the microservices world would have chosen a 3-tier for their implementation.

As the sub-heading suggest, one of the most important steps in moving to a microservices architecture is to understand the existing monolithic architecture. It is very important that the architect / technical decision maker has the knowledge of the product / enterprise software architecture of the existing system. The various contexts to understand the existing architecture include the following :

Core Functionalities / Core Features
Non-Core or Supporting Features
Major Issues Faced by the Application
Performance Reports - Load & Stress
Understand the Database Design
Identify Business Entities & Objects
Additional Resources - Messaging,...
Vision of Management for the Future

The idea is that the product features (core & non-core), performance, stability, scalability, business/domain entities or objects should be known to you to a certain extent before you decide on the microservices strategy. Only if you have a decent enough knowledge depth of the application in each of these contexts - you may be able to make the right decisions.

Challenges of Moving to Microservices Architecture

Overhead

The setup of microservices requires more efforts as there a lot of infrastructural architectural pieces as part of a complete microservices architecture. For example - api gateway, circuit breaker, discovery server, config server, health monitoring, vault service, token service, logging & auditing - these are just a few of the initial infrastructural services required to correctly implement a complete microservices architecture in the enterprise.

High Skill

There is a high skill level require especially in terms of experienced senior architects, devops and developers who can now understand the change in development paradigm. Also, this may either increase the development time or development costs or both.

Complexity

One of the most important disadvantages of microservices is the complexity involved. Even though the point is captured in the above 2 points - it still requires a mention on its own. The interplay of the plethora of infrastructural services along with the actual application microservices may create unending cycle(s) of complexity.

Redundancy

During development, the architects and lead engineers may need to keep a watch on making sure that there is no duplication of code, configuration or any other effort that may already have been developed by another team. This starts becoming a greater concern when there are geographically distributed teams and focussing entirely on their own set of business or product deliverables. Though some very trivial code duplication may be inevitable as far as possible - discipline will be required to isolate and group common functionality or code together correctly.

Data Duplication

One of the greatest challenge is data duplication. Most inexperienced architects and engineers may end up in such situations. It is because the thought that was required to build monolith data access and creation cannot now be used for microservices. The mechanism to maintain data integrity and data consistency in a product to make sure that there exists a correct 'single version of truth' needs to be planned, architected, and infused into the design.

Communication

The communication between external world and microservices or within microservices may fail. This could be due to multiple reasons including network failure and service unavailability. In any case, the communication between microservices is critical and is tough to setup and maintain. It also requires constant monitoring of health and performance of each of the microservices. Partial failures is actually an advantage of microservices - but still the monitoring, failure detection, failure handling and simply the internal/external communication can be quite an overhead in the implementation of microservices.

Maintenance

So, once the initial part is over - even if the microservices strategy and implementation turns out to be a success - it still means a heavy hit on the pocket for maintenance. Even though all of the current generation organizations rely on an external cloud provider, it still means more expenditure on hardware, 'software', cloud, devops engineers. Also, the total cost of ownership of such an infrastructural masterpiece is only bound to increase as more abstractions are added over time - also, the maintenance itself could be a complicated process.

Identify Monolithic Services to Move to Microservices

Core Features - Scalability

The Technical Stakeholder first needs to identify the core features that are candidate for scalability. As the success of a business might entirely depend on the scalability and success of its core features, this becomes one of the candidate in the business context as well. Also, most of the hardware of software resources' consumption will be by the core features. The most used features are almost always the core features. There might be services that fall into any of the above categories but are not scalable enough, especially at very high loads. In earlier architectural paradigms, It was required to scale the entire set of features - Now we can only identify the ones that meet our criteria and transform them to scale them independently.

Core Features - Stability

Almost always in a Software Application, some features or services maybe a painpoint in the context of stability. Few times these might be the core features. Now, without considering whether the instability is related to database, messaging, filesystem, external events, streaming data, poor programming, poor design, memory leaks or any such other reasons - These services become a candidate to be moved to Microservices Architecture. Here, the idea is not to conceal Inadequacy under Microservices - But to use Microservices either until the Issues are Fixed or just because the Services are 'unstable or unresponsive' at times due to the external dependencies of such services.

Performance Requirements

After the consideration of core features for scalability or stability, the Architect or Stakeholder has to enlist or note the features that have very strict performance requirements. Usually, the constraints were met while they were in a monolithic block - Either due to entropy or as a result of increased loads, recently there might be a notable deterioriation in their performance. With Microservices, now exists an opportunity to easily meet or exceed the Non-Functional Requirements or Performance Requirements.

Independent Scaling

There might be services existing in the Application that require Independent Scaling - This might be due to heavy database or such other resource usage. They may either be core or non-core features. Sometimes these features may be asynchronous or batch processes. All of these may qualify as Independently Scalable.

Independent Maintenance

Sometimes due to geographic distribution of domain knowledge, technical teams, support teams - The maintenance of parts of application will easily become a candidate for movement to Microservices. Now, this may also just simply because the company envisions a service to be Independently Maintenable as the tools or technologies are very niche and can be either maintained by external or internal specialist teams.

Independent Development

With Greenfield or Scratch Development, this becomes the most important candidate for Microservices - Independent Development across geographic teams, technical skill, domain competency are the reasons why the Microservices Architecture provides flexibility in development.

Research on Microservices Architecture

Literature Survey

Since Microservices is still a newer paradigm all over the world - Most Architects or Stakeholder(s) might be recently introduced to this topic. It is required that a good amount of literature survey is done by the Engineer in this regard to collect all relevant blueprint(s), standardized architecture diagram(s), design patterns, reference implementations, books/online books on the matter are referenced to come up with the Organizational Strategy.

Case Studies

As a subset of the above, but still requiring separate mention is a collection of case studies - that will allow the Architect to identify the Pitfalls, Failures and Shortcomings of Microservices as well as to revisit all shortcomings of the Monolithic Architecture. To learn from other mistakes also is a great advantage and allows the Architect to correlate the current situation to one of the other failed or successful case.

Understanding Microservices

Time has to be spent on understanding the essence of microservices and also the needs on why it was introduced and is popular in Software Development. This includes the Needs, Motivations and Advantages of Microservices (Refer my Earlier Article)

Applicability of Microservices

Applicability is one of the most important thing from the development perspective - either from a Technical or a Business Perspective. As the Architect might be well versed with the Product Architecture, Business and Technical Requirements - he needs to carefully and correctly understand the applicability within his context. By identifying and catching issues early, the Architect will save a lot of effort, pain and money for the Organization.

Microservices Design Patterns

Knowing the standardized Microservices Design Patterns beforehand or as and when faced with the issues is one of the important steps that an Architect must take to solve the problems faced using one of the generalized patterns or solutions. The pattern may be related to Database, Messaging, API, Security, Creation of Microservices.

Reference Implementation of Microservices Infrastructure

So, Almost 3 articles that were entirely dedicated to the Theory, Philosophy and Pragmatism of adopting Microservices. I bet every bit of experience and education that i have got, that each and every section of these articles will be Appreciated by the Architect or the Technical Decision Maker. Now, Here we are with some Energetic and Exciting News! The Reference Implementation - The Outcome of the entire series of these articles is in Obelix - A Reference Implementation for Microservices. It will be made available publicly on GitHub for any Student, Professional, Architect, Scientist to download and use in their Projects/Products.

[Microservices Readiness & Certification]

It is recommended that once the Architect or Technical Stakeholder is done with the Understanding the Microservices Architecture and is ready to start off the Implementation, he needs to also plan fo Microservices Readiness & Certification. The Idea of Readiness is to understand that whether the organization or product is ready to adopt microservices. Also, It includes a verification to find out if the organization really understands that Microservices is really applicable for their use case or needs. It should not be that since Microservices that is the new fad, It is being adopted by the organization. Also, once the architecture has been laid out - It needs to be certified as meeting the needs of the organization. It is not necessary to be meeting all standard components or guidelines, but it is very important that what has been proposed is what is required and can be sustained by the organization or product. In other words, we need to identify areas to improve and learn from them.

The best way to complete the Microservices Readiness Survey/Test, Microservices Applicability Survey/Test and Microservices Architecture Assessment Certification is to involve internal or external stakeholder(s). If the organization can spend budget on an external expert consultant to liasion with the Architect or internal stakeholder - It may yield great review outcomes and improve quality of the outcomes of the Architecture/Surveys. But If there are budgetary and other organizational constraints, another way is to have internal stakholder(s) who are Senior Technical Resources/Stakeholder(s) (Other Architects, Lead Engineers, Engineering Managers, QA Managers*, Product Managers*, Senior Management* : * - Optional) to form a Review Committee in the organization to prepare Surveys/Tests/Checklists and/or use online resources such as the one available at https://microservices.io/platform/ to evaluate themselves. Remember, the Implementation of Microservices might be 'very easy', if most Architectural and Implementation Issues can be foreseen and understood correctly.

[Obelix, Our Reference Implementation]

As mentioned earlier, the outcome of these articles is Obelix, The Microservices Reference Implementation. It is intended to be used directly in your applications (Especially Java/Java EE). It will try to provide a complete Microservice Infrastructure in terms of API Gateway, Circuit Breaker, Service Discovery, Config Server, Load Balancing Strategy, Config Server Bus Refresh, Messaging, Design Patterns, Service Mesh*, Docker*, Security, Sessions, Tokens, Data Access, K8s*, Maven, GitHub*, AWS*, Logging, Auditing and any Log Analysis. It may also act as the Architectual Basis for your ongoing Infrastructure or Product Development. The best suggested use will be to fork from the main branch for your Individual or Organizational needs. Oh! By the Way, I always consider Microservices a Mammoth Effort that makes many of the Ongoing Enterprise Needs Easy - So, Remembering One of my Favorite Cartoon Character Obelix from The Adventures of Asterix.

Fig. 1 : Obelix - The Microservices Reference Implementation (SKP's Microservices Masterclass Series)

Code Branching Strategy for Microservices Architecture

Organizational Code Branching

The Architect has to plan for the Code Branching Strategy in Tandem with DevOps and other Stakeholder(s). It is very important the Initial Planning also contains the Code Branching Strategy. One of the most important is to make sure that all parts of development such as Reference Implementation, Product Development, Feature Development and any Research & Development (Experimentation) is branched out. Merging from the Research Branches for all development branches should be planned based on Major Releases or Milestones. Also, there may be times that Research branches are much ahead than that can be used by Product Development or even that the Experimentation branches might deemed as [Not to be Merged] with the development branches.

Reference Implementation

The Reference Implementation Branch will be the one that every organization should create as part of their Initial Microservices Strategy. This will hold all the Infrastructure, PoC, Prototype for Product Development - Any code to demonstrate the use of Microservices Infrastructural Services as also the usage of Messaging, Containerization, Load Balancers, Mesh, Security, Logging, Auditing should all be placed here. Also, the Prototype or PoC for the general usage of developers should be placed here. There should also be a reference or usage guide along with videos (optional) that should allow Engineering Managers and Engineers to understand the use of the Microservices Reference Implementation Architecture. This is that one point of reference that is going to be the driving force in your entire Microservices Strategy. The Architect needs to plan for Releases and continuously mature the Reference Implementation. The core idea is that a Company's Strategic/Core Research team be made owners of the reference implementation branch. This should also be the branch where Architecture Validation Testing can be done, be it Functional or Non-Functional.

Product Development

The main consumers of the Reference Implementation or Microservices Architecture are the Product Development. In an IT Services environment, they may be known as the Application Development team. In any case, the Product Development Repository if already existing should be created afresh for the Purposes of Microservices based Product Development. Here, any of the Microservices Design Patterns may be used for the purposes of conversion of all existing Product Development APIs to the Microservices Architecture. The Product Development will have its own version of the Reference Implementation, just because there might be a reason for the Product Development to have some tie-up with the Reference Implementation - This may be in Configuration, Declaration, Code (!) or Deployment. The owners of the Product Development may be the Engineering Team.

At Release Times from the Reference Implementation branch, that may be decided by the Strategic Team in Tandem with Product Development Team, the code will have to be Merged in the Product Development branches. Most of the Merge will be Auto Merge except when conflict arises due to the specific product related changes. During this time, some collaboration may be required between the two teams.

Feature Development

Only in very certain cases, Specific Feature Development may be focused or disparate from the Product Development Repository. In these cases, the same process as above may have to be used in Feature Development. In normal circumstances, Feature Development is always branched from Product Development.

Next Gen Experimentation

Apart from all of these, Some organizations may have ongoing NextGen Product Architectures or ongoing Newer Product Development. During this time, a Baseline Microservices Reference Implementation Architecture may suffice for all Experimentation. Usually, the Initial phases of such development are purely for Experimentation around Business Logic, Newer Frameworks, Newer Technology, Newer UI/UX or Performance/Security Enhancements. In this case, the Merge may not be required at the frequent releases of the Reference Implementation, unless ofcourse the outcome depends on the Microservices Reference Implementation.

The above explanation is done for a Typical Product Development Organization - The Architect or Technical Stakeholder(s) can apply the Strategy based on their Organization's unique needs. But it is one very important part of the Microservices Strategy, to decide on Code Branching/Merging.

Rolling Out Microservices to Development (Dev Team)

Typical Real-World Checklist for Microservices Strategy (Planning Phase)

Provided Below is a Real-World Checklist for Microservices Strategy - This was from a successful execution of Microservices Strategy in a Product/Project. The Copyright/Proprietary Information (If Any) has been Removed from the Provided Table. This is actually created by a Principal Software Architect with contributions from Engineering Managers, DevOps Leads, Lead Engineers, Engineering Directors*, Product Managers*, Senior Management*.

Artifact 1 : Typical Real-World Checklist for Microservices Strategy (Planning Phase)

Typical Real World Checklist for Strategic Execution (Research Phase)

Provided Below is a Real-World Checklist for Microservices Execution in the Research Phase - This was from a Successful execution of Microservices Strategy in a Product/Project. The Copyright/Proprietary Information (If Any) has been Removed from the Provided Table. This is actually created by a Principal Software Architect with contributions from Engineering Managers, DevOps Leads, Engineers, Engineering Directors*. Few of the Tasks provided here can be considered as [Other Technical Activities Aligned to Microservices].

Artifact 2 : Typical Real-World Checklist for Microservices Strategy Execution (Research Phase)

Planning for Cloud and Containerization (DevOps Team)

The Planning for the DevOps Team Typical Revolves around the decisions on the below topics that should involve a DevOps Lead who under the guidance of a Principal Software Architect along with Engineering Managers, Lead Engineers and Senior Management will arrive at consensus.

Choice of Cloud Providers
No-Code and Low-Code
Native Cloud Usage
AWS*, Docker and K8s
ECR, ECS, EKS, K8s//EC2

Provided Below is a Real-World Comparison for Microservices using Spring Boot Stack versus Native Cloud (AWS). This was from a Successful execution of Microservices Strategy in a Product/Project using Spring Boot+ Stack on Amazon Web Services using ECR/ECS. The Copyright/Proprietary Information (If Any) has been Removed from the Provided Table. This is actually created by a Principal Software Architect with contributions from Engineering Managers, DevOps Leads.

AMAZON WEB SERVICES / CLOUD

SPRING BOOT OR CLOUD / JAVA

EASE OF USE

DevOps Should be Fine to Use

Easy as Java/J2EE - Spring Boot

LEARNING CURVE

DevOps is Fine, Dev Can be Steep

Is Gentle, All of It is Java / J2EE

DOCUMENTATION

DevOps is Fine, Dev Blogs Maybe Less

Documentation, Blogs will be High

MAINTENANCE

May Reduce Number of Servers

Multiple Server(s) May Exist for Roles

LICENCE / COST

Most of It will Require Payment

Almost Always, Will be Free

OPEN SOURCE

Not All of It is Open Source*

All of It is Open Source*

VENDOR LOCK-IN

Locked-In to AWS Ecosystem

Move Anywhere / No Lock-In

INTEGRATION EASE

Might be Simpler within Ecosystem

Will be Fine Across Ecosystems

SKILL AVAILABILITY

Tough to Get AWS API Skill

Easier to Get Spring Boot Skill

EXTENSIONS/INTEGRATION

Tougher to Write Extensions

Extensive Help to Integrate

MICROSERVICES CONCERNS

May Not Be Available to Extend Easily

Complete Microservices Architecture

PERFORMANCE

Possibly, Marginally Higher

Possibly, Marginally Lower

SECURITY

Possibly, Marginally Better

Possibly, Marginally Lower

SCALABILITY

Should be Highly Scalable, By Itself

Will be Almost Equivalent Scalable

MONITORING

Tools for Easier Monitoring/Logging

Might Need to Indirectly Hookup

TOOLS IN ECOSYSTEM

May Not Be Available to Extend Easily

Complete Microservices Architecture

COMPANIES USING

[Unable to Gather Information]

DEVOPS / DEVELOPMENT

DevOps Skill and Experience

Developer Skill & Experience

LINKS TO JUSTIFY

Artifact 3 : Planning for Cloud and Containerization (DevOps Team)

Microservices Architecture Validation (Testing Team)

Architecture Validation Testing

The Architecture Validation or Testing Architecture is required for any continuously evolving architecture. Now, Microservices by itself is a very Heavyweight Infrastructural Piece and it will undergo frequent updations as newer components are added, existing components are updated and any implementation context is changed between declarative, configuration and code. It is important that QA has a plan to test for the Architecture which includes a simple way to verify components like API Gateway, Circuit Breaker, Discovery Server and so on for positive and negative cases. So, By automating the architecture validation we are making sure of quality and sustained quality of the product. You need to put the tools to good ues, that available in your context or organization for the purpose of this automation. The discussion is beyond the scope of this article and I leave it as exercise for the reader. Please do leave your thoughts as comments to this article. Some articles related to DevOps and Testing Software Architecture and Testing Software Architecture might be good as starting points to read further on various ways to Test the Software Architecture.

Architecture Validation - Performance Testing

Just like Architecture Validation for 'Functional' aspects is very important - Dedicated or Automated Performance Testing for various components of the Architecture (and of the Architecture itself) is Very Important. At times, the Performance may deviate from the baseline performance set for Architecture Validation Testing, due to the changes in the components. This may catch the culprit changes early on and will be very helpful for the sanity of the Product Development Testing.

Planning for Microservices Testing

The Software Architecture of a Product will undergo Architecture Erosion - Term used to denote frequent changes and its Impact on the stability and performance of the Architecture. It is very important that during the time of the Microservices Strategy Planning (or atleast when the Most Important Phases of the Research are Complete) that the Microservices Architecture Testing is planned for. During this time, the Testing (QA) team should also be educated on what the Needs, Meaning and Motivations of the Microservices Architecture are.

Sample Tasks for Research & Development (Agile Sprints/Demos)

Sample High-Level Roadmap for Microservices

Provided Below is a Real-World High Level Task List for Microservices Roadmap for Senior Management/Stakeholder(s) to Adapt their Strategy from - This was from a Successful execution of Microservices Strategy in a Product/Project. The Copyright/Proprietary Information (If Any) has been Removed from the Provided Table. This is actually created by a Principal Software Architect with contributions from Engineering Managers, DevOps Leads, Engineers, Engineering Directors*. Few of the Tasks provided here can be considered as [Other Technical Activities Aligned to Microservices].

Artifact 4 : Sample High Level Roadmap for Microservices

Sample High-Level Milestone List for Microservices

Provided Below is a Real-World High Level Task List for Microservices Milestone List for Senior Management/Stakeholder(s) to Adapt their Strategy/Planning from - This was from a Successful execution of Microservices Strategy in a Product/Project. The Copyright/Proprietary Information (If Any) has been Removed from the Provided Table. This is actually created by a Principal Software Architect with contributions from Engineering Managers, DevOps Leads, Engineers, Engineering Directors*. Few of the Tasks provided here can be considered as [Other Technical Activities Aligned to Microservices].

Artifact 5 : Sample High Level Milestone List for Microservices

Sample High-Level Sequential Demos for Microservices

Provided Below is a Real-World High Level Task List for Microservices Demos List for Senior Management/Stakeholder(s) to Adapt their Strategy/Planning/Tasks from - This was from a Successful execution of Microservices Strategy in a Product/Project. The Copyright/Proprietary Information (If Any) has been Removed from the Provided Table. This is actually created by a Principal Software Architect with contributions from Engineering Managers, DevOps Leads, Engineers, Engineering Directors*. Few of the Tasks provided here can be considered as [Other Technical Activities Aligned to Microservices].

Artifact 6 : Sample High Level Milestone List for Microservices

Well, The Next Article in this Series will be the [Failures, Pitfalls & Disadvantages of Microservices]. Until Then, Wishing you a Great Strategy Time using Microservices!

[Side Note/Copyright Information]

Provided Tables and Lists are from a Real-World Microservices Strategy Execution in an Enterprise Java/Java EE Product. This was from a Successful execution of Microservices Strategy in a Product/Project using Spring Boot+ Stack on Amazon Web Services using ECR/ECS. The Copyright/Proprietary Information (If Any) has been Removed from the Provided Table. This was actually created by a Principal Software Architect with contributions from Engineering Managers, DevOps Leads, Lead Engineers, Product Managers*, Engineering Directors*, Senior Management*. It may turn out to be really useful to understand how the Real World Adoption goes on and can be planned for. Also, You may have your own context to add to the above Lists based on the Specifics of your Environment / Product.

SKP's Microservices #02 - The Needs and Motivations for Microservices

2024-09-07T10:00:00.006+05:30

Intro to SKP's Microservices Masterclass Series

Types (Evolution) of Software Architectures

Well, The Textbook of Software Architecture may want to classify the Types and Evolution of Software Architectures into Mulltiple Types and Sub-Types. But for all Practical Purposes, these four will be the Most Important Types of the Software Architecture that a modern day Software Architect may be able to identify. Almost all Modern Enterprise and Software Product Architecture can be classified into the following :

FIG.1 : EVOLUTION OF SOFTWARE ARCHITECTURES (IMAGE IS OBTAINED FROM GOOGLE SEARCH)

Monolithic Software Architecture

As the name suggests, Monolithic Architecture is Virtually a Single Block of Components to Serve all the Application Requests. It is one of the forms that has existed ever since Software Development and Software Engineering came into the world. It may be Distributed or Non-Distributed Application. Usually, In a Monolith the Implementation consists of Various Layers to achieve the functionalities as per the Application Requirements. Even though it may have few Asynchronous Components or Functionalities - For All Purposes, You can Imagine to be a Monolithic Block or Centralized Block, Consisting of Various Layers to Achieve the End Goal. Few Types of Monolithic Architecture are 2-Tier, 3-Tier or N-Tier Applications. You may Read more Specifically on Mononlithic Architectures from this Microsoft Link.
Service Oriented Architecture (SOA)

Service Oriented Architecture took the Thought Process of Software Architecture to a More Decentralized, Loosely Coupled Interactions Between Components to Serve the Application Requests. Mostly, the Initial Thoughts in SOA were for Disparate Enterprise Systems Interacting through a Shared Interaction Mechanism called as the Enterprise Bus. Service Oriented Architectures can be thought as a Coarse Grained Decentralization of Components to Achieve the End Goal. Service Oriented Architecture was Bulk, Heavyweight but was Able to Serve the Purpose of a Co-ordinating Set of Services/Systems (Possibly Monolithic Themselves).
Microservices Architecture (MSA)

The Architecture that is the State of the Art and has Caught on to Almost all Enterprises and every Medium to Large Software Development Project - Microservices Architecture (MSA). The Core Thought Involves True Decentralization of the Services or the Application and More Fine Grained Splitting or Division of Application Services into Individual Services of their Own. Also, MSA brings in a Newer and Complex Form of Infrastructural Services to Aid in the Real Ownership of Respective Infrastructural Responsibility. Though, It has it's own Set of Disadvantages (Will be Discussed Later in this Series of Articles) - It allows for Independent Scaling and 'Selling' of Services to a Customer or any External Stakeholder.

FIG.2 : DETAILED VISUALIZATION OF LAYER WISE/FUNCTION WISE FOR MONOLITH vs. MICROSERVICES vs. SERVERLESS
(IMAGE CREDITS TO XENONSTACK)

Shortcomings of the Monolithic Systems (Promise of Microservices Architecture)

Development
Monolithic Systems were built by a Single Focussed Team that maybe Geographically Dispersed - Mostly the Concerns of the Architecture, Layer Wise or Feature Wise Might be the way Development Teams of Varying Specialities are Organized. Most of the Times, these Teams will be on the Same Broad Skill Set or Technology Stack. Now, Although this is Correct - It Does Not Truly Allow a Team to Completely Concentrate on a Problem or a Feature (In-Whole). Also, There is a Chance in the Same Organization People of Different Skills or Technologies might want to Come Together in an Organization to Build the Application Features or Components. Each of them may want to Layer their Individual Components to their Own Specific Needs/Ecosystem. This was not Possibe with Monolithic Systems.

Promise of Microservices
With the Advent of Microservices, The New Promise of Truly Allowing Development Teams to Focus on their Specific Components or Services Irrespective of the Technology Stack, Layering (Specific Architecture), It's Own Database (Not Just Schema) - This Allows Global Teams Now to Concentrate on their Development without the Need to Co-ordinate with Other Teams except for Common Components, Interaction Mechanism or Infrastructure Services.

Coupling
The Systems built with the Monolithic Thought Process are More Tightly Coupled Across Layers or Across Components - Since they Reside on the Same 'Server Function' most of the Times - Services or Components are More Tightly Coupled. Even though by Building with Correct SOLID and OOPs Paradigms - They may Still Be Considered to be More Tightly Coupled as a Result of Being Packaged in the Same Binary.

Promise of Microservices
With Microservices, Each of the Services can be Made Truly Independent of Each Other and thereby Really 'Loosely Coupled'. They will be Deployed on Disparate Servers and Can Now Even be Considered to be Built with any Technology that is the Expertise of the Company/Unit.

Scalability
Monolithic Systems, especially those ones with lots of Non Functional Requirements related to Performance and also Scalability. These Systems are usually marred by Symmetric Scalability but this will lead to System Resources being shared between the Services that do not have Scalability Requirements and ones that have Scalability Requirements. Usually Systems Need Asymmetric Scalability wherein the Core Features or Core Business Logic Services May Have Higher Scalability Requirements and the Helper or Non-Core Features might be Have Very Less Hardware or Memory Requirements.

Promise of Microservices
With the Advent of Microservices, One of the Greatest Advantages is that it allows us to Architect/Design Systems that can Scale Independently at Every Level - Whether it is Service Level or at the Database Level or any Resource that may otherwise have been Shared. This will allow us to Plan and Size for Systems Accurately and More (Cost-) Effectively. The Organization will get (almost) Every Worth of their Penny through Accurate Sizing/Scaling Excercises. The Resources will be Allocated and Used as the Actual Customer Usage Reflects in the Budgeting. Although the Challenges Introduced Now by Communication Mechanisms within Microservices or Distributed Database Transaction Mechanism may Result in Negative Outcomes. The Performance and Scalability of Microservices will be Discussed in Detail in my Future Articles in this Series.

Availability
Now the Availability Needs to be Thought as a Different Technical Requirement Different from Others - With Monolithic Systems, If a Server Comes Down - Almost Always, the Entire Application Stops Responding - Even If it is Highly Available, There maybe times at Peak Load - The System Stops Responding or Slows Down to the Point that the Application is Actually Unavailable.

Promise of Microservices
In the Micorservices World, the Independent Nature of Services Now Allows us to Plan for High Availability Much Easier and Fault Tolerance, Failure Recovery, Retry on Fail Mechanism are Now More Automated and Efficient. Also, The Failure of a Single Service will Never Bring the Entire Application Down. For Mission Critical Systems, this is a Great Advantage as Parts of Systems or Features will Keep Responding even though Few Services Have Failed in the Ecosystem.

Performance
Performance in the Monolithic World will have to be Planned for the Entire Application. This also Includes Performance Testing. Just as Described Earlier - The Parts of the System that are Severe Load might actually cause the Entire System to Slow Down. Though this Point is Very Similar to the Scalability Point - You always have to Note that the Performance of a System or API will have to be Accounted Separately from the Scalability. Though the Same Reasons Apply, It has to be thought of as a Localized or in a API Specific Notion.

Promise of Microservices
In Theory, The Performance of Microservices should ideally be Greater than the Same Monolithic Service since the Application/Feature will now have its own Server, Database and Resources - But Since the Microservices have a Lot of Infrastructural Services and the Communication Overhead may Result in a Negative Outcome. This Topic will be Discussed Further in my Future Articles - For Now, You have to Simply Note that If a Monolithic Service were to be Built on a Database Per Microservice Kind of Architecture, It is Bound to Perform much Higher than it's Monolithic Counterpart.

Infrastructure
Monolithic Systems - Though, In Existence from almost the Advent of Software Engineering - Never Had Some Standardized Infrastructure Components - Even Though with the Advent of SOA, Few of the Infrastructural Components started Finding their Place in Software Architecture - Most of the time Infrastructural Abilities for Service Availability, Failure Recovery, Configuration Management, Service Health, Service Discovery, Security Infrastructure, Messaging Mechanisms, Logging, Log Analysis, [Many More Concerns] where mostly Built or Incorporate in a Very Custom Way Per Project or Product.

Promise of Microservices
With Microservices, Mostly there is a Widely Agreed Upon Standardized Architecture that is a Master Blueprint for Organizations to Follow for their Microservices Architecture. Even If Companies were to Adopt/Implement only Partial Infrastructural Component from the Said Standard - It will still mean that there is Uniformity in the Way Microservices are Implemented. There are many [Make or Built] of the Actual Infrastructural Frameworks that are Available for these Standardized Requirements. The Organization or the Microservices Architect may use any of them, Based on the Suitability to their Environment.

Business
Well, the Most Important Outcome of Engineering is almost always that the Innovation or the Product is More Easily Available or Sellable to the Market. The Greatest Advantage is that Business <> Engineering Bridge is More Complicated or May Need More Time to Deliver On in the Case of Monolithic Architecture. Also, the Product is almost always thought as a Complete Unit and will be Sold as a Subscription or Fixed Price or Pay as you Go Mechanism. Usually, when a Customer wants only a Few of the Services or Features, Business Teams would Bundle It up - But Under the Hood the Product would Still Be One Large Unit of Code/Binary.

Promise of Microservices
Inherently, with Microservices Architecture - The Business Advantage is the ability to Independently Sell/Size the Services and the Associated Hardware or Resources for a Customer. Now, the Business can Plan for Subscription, Pay As You Go, Fixed Price at a Service Level Much 'Easily'. Also, Any New Service or Even Custom Services can be Easily Planned, Independently Built and Incorporated into the Entire Product Ecosystem at a Customer or Product Level.

FIG.3 : FEATURES/CHARACTERISTICS OF EACH TYPE OF ARCHITECTURE (CREDITS TO www.rubygarage.org - OBTAINED FROM GOOGLE SEARCH)

The Above Image Shows the Features of Each Type of Software Architecture and the Most Important Grade of Companies or Applications that they are Suitable For. Our Focus in this Article in on the Details of Shortcomings of Monolithic Systems (As the Most Important or Prevalent Type of Software Architecture in Use Before Microservices) - As of Today, In 2021, Companies are in a Mad Fervor to Move Completely to Microservices or Hybrid Varities of Microservices.

Challenges of Microservices Architecture

Overhead
The Setup of Microservices Requires More Efforts as there a Lot of Infrastructural Architectural Pieces as part of a Complete Microservices Architecture. For Example - API Gateway, Circuit Breaker, Discovery Server, Config Server, Health Monitoring, Vault Service, Token Service, Logging & Auditing - These are Just a Few of the Initial Infrastructural Services Required to Correctly Implement a Complete Microservices Architecture in the Enterprise.

High Skill
There is a High Skill Level Require Especially in Terms of Experienced Senior Architects, DevOps and Developers who can Now Understand the Change in Development Paradigm. Also, This May Either Increase the Development Time or Development Costs or Both.

Complexity
One of The Most Important Disadvantages of Microservices is the Complexity Involved. Even Though the Point is Captured in the Above 2 Points - It Still Requires a Mention on its Own. The Interplay of the Plethora of Infrastructural Services along with the Actual Application Microservices may Create Unending Cycle(s) of Complexity.

Redundancy
During Development, the Architects and Lead Engineers may Need to Keep a Watch on Making Sure that there is No Duplication of Code, Configuration or any other Effort that may Already have been Developed by Another Team. This Starts Becoming a Greater Concern when there are Geographically Distributed Teams and Focussing Entirely on their Own Set of Business or Product Deliverables. Though some very Trivial Code Duplication may be Inevitable as far as Possible - Discipline will be Required to Isolate and Group Common Functionality or Code Together Correctly.

Data Duplication
One of the Greatest Challenge is Data Duplication. Most Inexperienced Architects and Engineers may end up in Such Situations. It is because the Thought that was required to Build Monolith Data Access and Creation cannot Now be used for Microservices. The Mechanism to Maintain Data Integrity and Data Consistency in a Product to Make Sure that There Exits a Correct 'Single Version of Truth' Needs to be Planned, Architected and Infused into the Design.

Communication
The Communication Between External World and Microservices or within Microservices may Fail. This could be Due to Multiple Reasons Including Network Failure and Service Unavailability. In any Case, The Communication Between Microservices is Critical and is Tough to Setup and Maintain. It also Requires Constant Monitoring of Health and Performance of Each of the Microservices. Partial Failures is actually an Advantage of Microservices - But Still the Monitoring, Failure Detection, Failure Handling and Simply the Internal/External Communication can be Quite an Overhead in the Implementation of Microservices.

Maintenance
So, Once the Initial Part is Over - Even If the Microservices Strategy and Implementation Turns out to be a Success - It still Means a Heavy Hit on the Pocket for Maintenance. Even though all of the Current Generation Organizations Rely on an External Cloud Provider, It Still Means More Expenditure on Hardware, 'Software', Cloud, DevOps Engineers. Also, the Total Cost of Ownership of Such an Infrastructural Masterpiece is Only Bound to Increase as More Abstractions are Added Over Time - Also, The Maintenance Itself could be a Complicated Process.

True Cloud Applications and Containerization

AWS, GCP, Azure and More
At the turn of the Decade (2010s), Came the Dawn of the True Cloud Native Applications - Most Popular of the Cloud Providers Being Amazon Web Servics, Microsoft Azure, Google Cloud Platform. The Paradigm of Deployment Now Moved from a On-Premise, Hosted to a Public Cloud or Private Cloud. Now, Microservices that Slowly caught on Speed by around 2015s and The Adoption has Never Stopped Since. As of 2021. Almost 50%* of the World's Application Being Built using the Microservices Architecture (Either Entirely, Partially or Hybrid) - Now True Cloud Native Applications and Microservices are Not Exactly an Equivalent - But the Cloud Providers are Able to Provide Most of the Infrastructure in their Own Ecosystem. So, We can Say the True Cloud Native Environments have Ready Support for Microservices Infrastructure and Architecture.

Docker, Kubernetes and ++
Docker and Kubernetes and Any Other Container Technology Tools are a Modern Day Enhanced Equivalent of a Web Server or Application Server, except that the Function is to Now Vendor Neutrally Deploy Images and Allow Multiple DevOps Functions to be Carried Out on the Images - Such as Configuration, Clustering or Communication. Docker and Kubernetes have Become the Gold Standard for Enterprise Software - With Docker Being Popular for Containerization and Kubernetes for Container Orchestration. Now, Docker and Kubernetes will Allow Monolithic Architecture to be Deployed as Welll - But the Containerization Paradigm has a One is to One Correlation with Microservices as Both Allow an Independent Nature of DevOps and when Combined with True Cloud Providers - They Become the Modern Day Development & Operations Engine for Deployment, Maintenance, Containerization, Cloud, Scalability, Availability, Failure Recovery, Configuration, Communication and More Infrastructural Concerns.

The State of Microservices in 2021

As of 2021, As a Principal Software Architect in the Software Industry - Being Part of Almost 4 Companies that Have Adopted or Started to Adopt Microservices (Especially Using Spring Boot, Spring Cloud, Spring Data, Spring Security, Netflix OSS as Java/Java EE Stack is my Area of Expertise) - I can now Safely say that almost all Companies have either Moved to or In the Process of Moving to Microservices. This is Due to the Obvious Advantages and Promises of Microservices. Every Technology in History has Brought with it a Newer Set of Problems whcih Engineers and Architects have Solved in their Newer Counterparts. Neverthless, Microservices is one such Engineering Innovation. In the Future Articles in this Series, We shall Look at the Issues that are Faced by Microservices Themselves, In Detail. The Below Categorization Clearly Shows that Microservices and its Hybrid Varities are Slowly Displacing Monolithic and SOA Architectures in the Enterprise and in Software Development Projects.

The Only Word of Caution would Remain for Architects, Decision Makers and Organizations is to Make Well Researched and Reasoned Out Decisions. Microservices should not simply be thought as a Silver Bullet for Every Problem that a Product or a Service is Facing. Alternative or Hybrid Ways should also be Considered. Various Considerations like Budget, Maintenance Costs, Resources, Skill Availability, Vision, Timelines, Current Ecosystem among Others shoould be thoroughly Understood and Justified before an Organization Takes a Plunge to Microservices. Even though Microservices Holds Promise to Solve a Lot of Issues that Marred Monolithic Architecture, Few Organizations and Architects Do Not Totally Agree with the Advantages that Microservices have to Offer. It also remains to be Seen if the MSA will again Evolve (Converge or Diverge) into Much Simpler or Even Complicated Architecture Types of the Future.

FIG.4 : THE 2021 STATE OF MICROSERVICES REPORT (CREDITS TO www.jrebel.org - OBTAINED FROM GOOGLE SEARCH)

Well, The Next Article in this Series will be [Moving from Monolith to Microservices]. Until Then, Wishing you a Fulfilling Time with Microservices!

SKP's Microservices #01 - The Pains of Monolithic Architecture

2024-09-01T10:00:00.016+05:30

Intro to SKP's Microservices Masterclass Series

FIG.1 : Typical Three-Tier Architecture
(Source : IBM, Available on Google Search)

Explanation of a Typical Monolithic Architecture

SKP's Microservices Masterclass - The Most Common Software Architecture that One can Safely Say has been in Existence ever Since Software Development Started - It is the Monolithic Architecture. There have been many forms of Monolith over the Ages. A Single Block of Software (Such as Desktop), Distributed Architectures such as 2-Tier, 3-Tier, N-Tier are all examples of Monolithic Architecture. For the Sake of this Article, We will use the Most Common and Standarized Example of a 3-Tier Monolithic Architecture. Most Enterprise Systems Prior to the Microservices World would have chosen a 3-Tier for their Implementation.

Tier vs Layer

Before we delve into the details of monolithic architecture, I think this will be an interesting topic to discuss. Tiers are physical separations of groups, of similar or dissimilar kind of layers, that run on the same physical infrastructure. Layers are logical or functional groupings while tiers are physically separated units. For example, the User Interface renders on browser - hence, it qualifies as a disparate existence (physical) with a specific concern (logical) - the Client Tier. Next, the Web Layer or Presentation Layer might exist along with a Business Layer either each of them on a Web Server (Web or Presentation Tier) and Application Server (Business Tier) respectively. They may also be deployed together on an Application Server (Presentation Layer runs in the Web Container and Business Layer runs in the Application Container). Hence, this qualifies as a single grouping of deployments (physical) having different concerns (logical) - the Middle Tier. Next, the Database Schema (logical) will be on a Database Tier or Enterprise Information Systems-EIS Tier (physical). Hence, you must note that a tier is different from a layer. Note that in some web development textbooks or in practical usage - the web or presentation tier might be shown as the first one, ignoring the client tier. The user interface is rendered on the client tier by this presentation tier. The presentation tier prepares the user interface for rendering based on the data that is returned by the business tier, which gets it from the database tier. From this introduction, you can understand that tiers are physical deployments of logical layers. Groups of layers, similar or dissimilar, that operate on the same infrastructure are also said to divide into tiers.

Let us Now Get Into a Detailed Explanation of Each Important Tier in the 3-Tier Architecture.

First is the Client Tier. Now, The Client Tier is something that is Entirely on the Client or the End Visible User Interface of the Application. This will be Rendered by the Web Container as in the Below Diagram. The End User will interact with the Application through this User Interface Rendered on the Client Tier. Our Explanation is Based on a Web (DHTML) User Interface Rendered on the Browser on a Personal Computer. In the Below Diagram, Application Client Container can be considered as a Desktop User Interface or a Technology that Renders within the Specifics of that Container (For the Web Applications, Browser can be thought of as a Container). Mostly, the Simple Validations, Filling Forms, Printing, Viewing, Simple Logic is the Kind of [Operations] performed on a Browser Rendered User Interface. The Technologies can be HTML, CSS, Javascript, Angular, JavaFX, GTK, Qt,...

Moving to the Application Tier. In the J2EE World, we can also think of this as the J2EE Application Server Layer. Traditionally, this has 2 Main Layers - the Web Container and the Application Container (EJB Container). Here we can Appreciate the Difference between Layers and Tiers. The Web Container or Web Layer will hold the Web Rendering Components of the Application. You may also visualize it as a Different Physical Deployment on a Web Server. The Examples of Technologies in this Layer and Container are JSP, Servlet, Struts (MVC), JAX-RS (REST), JAX-WS (SOAP), Spring (MVC), ASP.NET, PHP,...

The EJB Container can be Visualized as the Core Application or Business Logic Container of any Application. This is an Independent Layer of Deployment. Even though In the Below Diagram it is mentioned as EJB Container, You may just call it as the Application Container or Application Layer or Business Layer. All the Brain/Heart/Logic of an Application will always lie in this Layer - This can actually be termed as the Application Itself. It's Primary Functions include to Interact with Database, Process Business Logic and Send Data/Objects to the Web Container. Examples of Technologies in this Layer and Container are EJB, Spring (Remoting/POJO), [Windows Service*], Core Java (POJO),... You have to Understand that the Application Layer Need Not Always be an Application Server - It Might be that a Web Technology such as JAX-RS (REST), JAX-WS (SOAP) may be used for this Purpose.

FIG.2 : Typical J2EE Architecture (3-Tier with Layer Separation into Web and EJB Containers)

[Obtained from Google Search]

(Note that the Web Container will Render UI and EJB Container will Process Business Logic and Access Database)

Moving to the Data Tier. This may be Referred to as the Database Server or Data Layer. The Purpose is clear and easily deduced from the Naming - It is used to store the Data - For the Purpose of this Article, You may visualize it as RDBMS or Database. The Database may have various Schemas, Tables that store the Application Data. Some of the Flavours of RDBMS are Oracle, MySQL, PostgreSQL, DB2, ... You have to Note Some Authors may call this EIS Tier (Enterprise Information Services Tier) - Also, Note that Data may not always Reside in a RDBMS - It may be NoSQL, Other Web Services (Data Sources), Streaming Data Sources, Connected Devices, Unstructured Data, File Systems or any Other Form of Data that may Need to be Accessed/Processed by an Application.

Disadvantages of Monolithic Architecture

Development

Monolithic Systems were built by a Single Focussed Team that maybe Geographically Dispersed - Mostly the Concerns of the Architecture, Layer Wise or Feature Wise Might be the way Development Teams of Varying Specialities are Organized. Most of the Times, these Teams will be on the Same Broad Skill Set or Technology Stack. Now, Although this is Correct - It Does Not Truly Allow a Team to Completely Concentrate on a Problem or a Feature (In-Whole). Also, There is a Chance in the Same Organization People of Different Skills or Technologies might want to Come Together in an Organization to Build the Application Features or Components. Each of them may want to Layer their Individual Components to their Own Specific Needs/Ecosystem. This was not Possibe with Monolithic Systems.

Coupling

The Systems built with the Monolithic Thought Process are More Tightly Coupled Across Layers or Across Components - Since they Reside on the Same 'Server Function' most of the Times - Services or Components are More Tightly Coupled. Even though by Building with Correct SOLID and OOPs Paradigms - They may Still Be Considered to be More Tightly Coupled as a Result of Being Packaged in the Same Binary.

Scalability

Monolithic Systems, especially those ones with lots of Non Functional Requirements related to Performance and also Scalability. These Systems are usually marred by Symmetric Scalability but this will lead to System Resources being shared between the Services that do not have Scalability Requirements and ones that have Scalability Requirements. Usually Systems Need Asymmetric Scalability wherein the Core Features or Core Business Logic Services May Have Higher Scalability Requirements and the Helper or Non-Core Features might be Have Very Less Hardware or Memory Requirements.

Availability

Now the Availability Needs to be Thought as a Different Technical Requirement Different from Others - With Monolithic Systems, If a Server Comes Down - Almost Always, the Entire Application Stops Responding - Even If it is Highly Available, There maybe times at Peak Load - The System Stops Responding or Slows Down to the Point that the Application is Actually Unavailable.

Performance

Performance in the Monolithic World will have to be Planned for the Entire Application. This also Includes Performance Testing. Just as Described Earlier - The Parts of the System that are Severe Load might actually cause the Entire System to Slow Down. Though this Point is Very Similar to the Scalability Point - You always have to Note that the Performance of a System or API will have to be Accounted Separately from the Scalability. Though the Same Reasons Apply, It has to be thought of as a Localized or in a API Specific Notion.

Infrastructure

Monolithic Systems - Though, In Existence from almost the Advent of Software Engineering - Never Had Some Standardized Infrastructure Components - Even Though with the Advent of SOA, Few of the Infrastructural Components started Finding their Place in Software Architecture - Most of the time Infrastructural Abilities for Service Availability, Failure Recovery, Configuration Management, Service Health, Service Discovery, Security Infrastructure, Messaging Mechanisms, Logging, Log Analysis, [Many More Concerns] where mostly Built or Incorporate in a Very Custom Way Per Project or Product.

Business

Well, the Most Important Outcome of Engineering is almost always that the Innovation or the Product is More Easily Available or Sellable to the Market. The Greatest Advantage is that Business <> Engineering Bridge is More Complicated or May Need More Time to Deliver On in the Case of Monolithic Architecture. Also, the Product is almost always thought as a Complete Unit and will be Sold as a Subscription or Fixed Price or Pay as you Go Mechanism. Usually, when a Customer wants only a Few of the Services or Features, Business Teams would Bundle It up - But Under the Hood the Product would Still Be One Large Unit of Code/Binary.

Database - The Albatross Around the Architect's Neck

We Need to Discuss this Topic in Detail as this is the One cause the Much Performance, Scalability, Stability (Reliability), Availability Issues Many a Times in the Enterprise Software Development World. One of the Primary Motivations or Outcomes of a Microservices Architecture by Providing a Database Per Service Architecture. Most of the Times, an Architect is given the arduous Task of Meeting, Delivering and Exceeding Not only the Functional Requirements but also the Non-Functional Requirements. Now, when we speak of the Non-Functional Requirements we can Talk of Performance, Scalability, Stability and Availability in One Breath. Even though they are related, they all usually need to be Handled Separately. Most of the Time, these Issues have One is to One Correlation with the Database Performance and Scalability. If Not with the Database, they may have to do with Data Access Layers of the Application. Also Note when we Simply Mention Database Here we mean RDBMS. Most Enterprise Applications and Products are Built on RDBMS/Database.

For Almost Every Request to an Application, The Database is that one Critical Resource Decides The Performance. As the Load (Number of Requests), The Database Can Deteriorate the Performance - Also, In Effect the Increase on an Application Reduces the Performance for Each Request or Query to a Point that the Application Response Time may become Unacceptable. This is Termed as the Scalability of the Application (or the Database). Once the Requests Exceed a Given Threshold, the Application May Become Unstable and there might be Requests that either are Served Very Slowly or Not Served at All. Even though Measures Exist to Put this in Check, the Number of Active Requests may Increase to such an Extent that the Application or Database Becomes Unavailable or Involuntarily Terminates. So, The Entire Effort in Application Architecture and Design Now are Focussed to Make Sure that Application Meets the Performance, Scalability, Stability and Availability Based Non-Functional Requirements. The Point that is Being Tried to be Driven Across is that Database is One Resource which is almost always the One that is the Biggest Bottleneck to Meet these Requirements. Even with Adequate Functional, Load, Stress or Soak Test - The Application may Fail while In Real-World Production Environments.

With the Above Discussion, It is clear that More Often than Not - Database or RDBMS Becomes the Albatross Around the Software Architect's Neck - The Single Point of Concern that May Even Decide the Success of an Application, Product or Business!

The Promise of Microservices Architecture

FIG.3 : Visualization of Monolithic vs Microservices (Software Architectures)

(Image Rights with Knoldus Blogs)

Promise of Microservices for Development Teams

With the Advent of Microservices, The New Promise of Truly Allowing Development Teams to Focus on their Specific Components or Services Irrespective of the Technology Stack, Layering (Specific Architecture), It's Own Database (Not Just Schema) - This Allows Global Teams Now to Concentrate on their Development without the Need to Co-ordinate with Other Teams except for Common Components, Interaction Mechanism or Infrastructure Services.

Promise of Microservices for More Independence

With Microservices, Each of the Services can be Made Truly Independent of Each Other and thereby Really 'Loosely Coupled'. They will be Deployed on Disparate Servers and Can Now Even be Considered to be Built with any Technology that is the Expertise of the Company/Unit.

Promise of Microservices for Scalability

With the Advent of Microservices, One of the Greatest Advantages is that it allows us to Architect/Design Systems that can Scale Independently at Every Level - Whether it is Service Level or at the Database Level or any Resource that may otherwise have been Shared. This will allow us to Plan and Size for Systems Accurately and More (Cost-) Effectively. The Organization will get (almost) Every Worth of their Penny through Accurate Sizing/Scaling Excercises. The Resources will be Allocated and Used as the Actual Customer Usage Reflects in the Budgeting. Although the Challenges Introduced Now by Communication Mechanisms within Microservices or Distributed Database Transaction Mechanism may Result in Negative Outcomes. The Performance and Scalability of Microservices will be Discussed in Detail in my Future Articles in this Series.

Promise of Microservices for Avaialability

In the Micorservices World, the Independent Nature of Services Now Allows us to Plan for High Availability Much Easier and Fault Tolerance, Failure Recovery, Retry on Fail Mechanism are Now More Automated and Efficient. Also, The Failure of a Single Service will Never Bring the Entire Application Down. For Mission Critical Systems, this is a Great Advantage as Parts of Systems or Features will Keep Responding even though Few Services Have Failed in the Ecosystem.

Promise of Microservices for Performance

In Theory, The Performance of Microservices should ideally be Greater than the Same Monolithic Service since the Application/Feature will now have its own Server, Database and Resources - But Since the Microservices have a Lot of Infrastructural Services and the Communication Overhead may Result in a Negative Outcome. This Topic will be Discussed Further in my Future Articles - For Now, You have to Simply Note that If a Monolithic Service were to be Built on a Database Per Microservice Kind of Architecture, It is Bound to Perform much Higher than it's Monolithic Counterpart.

Promise of Microservices for Infrastructure

With Microservices, Mostly there is a Widely Agreed Upon Standardized Architecture that is a Master Blueprint for Organizations to Follow for their Microservices Architecture. Even If Companies were to Adopt/Implement only Partial Infrastructural Component from the Said Standard - It will still mean that there is Uniformity in the Way Microservices are Implemented. There are many [Make or Built] of the Actual Infrastructural Frameworks that are Available for these Standardized Requirements. The Organization or the Microservices Architect may use any of them, Based on the Suitability to their Environment.

Promise of Microservices for Business

Inherently, with Microservices Architecture - The Business Advantage is the ability to Independently Sell/Size the Services and the Associated Hardware or Resources for a Customer. Now, the Business can Plan for Subscription, Pay As You Go, Fixed Price at a Service Level Much 'Easily'. Also, Any New Service or Even Custom Services can be Easily Planned, Independently Built and Incorporated into the Entire Product Ecosystem at a Customer or Product Level.

FIG.4 : Microservices - The Reigning Champion (Already?) In the War of Software Architectures
(Image Rights with Thoughtworks)

Well, The Next Article in this Series will be [The Needs and Motivations for Microservices]. Until Then, Wishing you an Inquisitive Time with Microservices!

Winning in Online Skilled Gaming… Err… Gambling! [Part 04]

2023-12-23T11:22:00.016+05:30

Optimistic+ (My Creation)
(Best Applied to Baccarat Class of Games)

If you have played any of the baccarat class of games like dragon tiger, cricket war or football studio – you may find that it virtually is a 50% probability game on either side – not including the tie or suited tie that happens once in a while. Now, in this class of games the experienced gamer even by using the fibonacci technique, might still end up losing big. This is because of long streaks of a specific side winning again and again, combined with the dogged approach of the fibonacci player and the act of continuing beyond the safe limits without bet auto stoppers. Now, even with bet auto stoppers in place, you may not be able to win as much.

Hence, the optimistic+ algorithm. The naming of the algorithm is due to ‘the optimistic belief that a side that is winning will continue to win’. Now, rather than betting on a side that will eventually win, you continue betting on the side that is winning. For most baccarat style 2 card games, this approach will yield more to the player. But you still need to have the safe limits operation using the bet auto stoppers.

You can observe from the above that using fibonacci, the player started him game set every time at 100, and progressed via fibonacci series bets of 100, 200, 300 and so on… In the above game, the player had started continuously betting on Side 1, after analyzing the game dynamics, believing that we will get the greatest return on Side 1 using the ‘Never Lose’ strategy with ‘Bet Auto Stopper’. If you have understood this article well and have played the casino games for some time, you can easily see that he has total winnings of -100, that is an overall loss of 100. This is because he continued with an pessimistic approach that he will eventually win with his bets on Side 1.

Now, let us take a look at the optimistic+ strategy. In this case, the player starts simply betting on the side that had last won. In this case, he can either use the progressive style of betting or fibonacci to place the bets. So, you observe that he has a total winning amount of 700. Now, this technique allows you to win on a board that is continuously producing mini, medium or long sequences of the same winning side. But on a board, where the result is continuously alternating between side 1 and side 2, you might end up losing for some time, until the game again settles into sequences of one side. If there are really long sequences of alternating sides, you may choose to stop for some time, take a mini break and then come back to start off betting on the winning side.

Almost always this strategy is going to yield. But you need to combine with either fibonacci or progressive style along with the bet auto stoppers or quantum+ algorithm.

Ploppy 3:2 with 0 Technique
(Technique is Used for Roulette Class of Games)

This is a time-tested technique and the internet provides many articles and videos on how to apply and use this technique. Let me describe this technique once again over here, but very briefly.

The idea of ploppy 3:2 is to increase your chances/probability of winning in every spin at the table. You have to place 2 bets simultaneously, in the amount ratio of 3:2, with 3/5^th amount being placed on an even money payout slot like [black] on a roulette table and 2/5^th of the amount being placed on a 2 to 1 slot for the top row.

For example, if you choose to place the 3/5 bet amount on all [black numbers], you are covering 18/36 numbers and if you choose to place the 2/5 bet amount on the top row [3-36] numbers, you are covering 12/36 number. If we were to remove the common numbers, the probability increases to 26/36. But you have to note that we are ignoring the green [0] in this probability – which usually turns up sometimes as the winner and pays handsomely like 25x, 30x or 36x. Some of the roulette version have gold bars or multipliers placed and as per my observation, it lands on the green number [0] more often. Hence, the chance of that bonus amount via multiplier increases. Hence, my technique is an adaptation of the ploppy 3:2 with 0.

If you have understood the mathematical basis above, you will be able to apply it in variants, so as to bet on maximum numbers in one go. For example, you may place the 3/5 bet amount on all [red numbers], combined with 2/5 bet on the second row [2-35].

You may combine Ploppy 3:2 with 0 Technique, with fibonacci, progressive bets or quantum techniques. But the reasoning in ploppy 3:2 or in other games to place the bets on specific section or number, coined by me, is called by me as the Late Appearing Section on Table (LAST). So, Betting via LAST works on the concept that the section/number that occurred least frequently (or the most earliest in the win sequence) has a greater chance of appearing again. The opposite of this reasoning is Fresh Appearing Section on Table (FAST). FAST is very close to our Optimistic+ strategy, only that FAST will be used in combination with others, on table games with lots many number to bet, like Roulette Class of Games and Optimistic+ is ideal for Baccarat Class of Games.

Winning Sequence on Table (Last Winning Number at the Start): 31, 28, 1, 30, 36, 24, 13, 10, 29, 0, 0, 7, 5, 22, 22, 18, 15, 34, 34, 35

Using LAST Reasoning, My Prediction is that Next Winning Number will be from Top Row [3-36] as it occurred earliest in sequence.

Using FAST Reasoning, My Prediction is that Next Winning Number will be from Row #2 [2-25] as it recently occurred in sequence.

Please also take a look at the Table Statistics provided by Online Casinos, to refine or optimize your bets using the above reasoning

You see that in the above self-explanatory game set, driven by variant of progressive bets and using LAST reasoning – The player has ended up with +0070 winnings. With few good decisions or using FAST reasoning, the outcomes could have been better. Fibonacci may also be used in combination with Ploppy 3:2 with 0. So, based on the current statistics of winning numbers you can make better decisions and apply the above technique to win at roulette class of games.

Remember, once you learn, understand and apply to win (or lose) using the above techniques – You will very easily be able to combine the techniques to achieve success at online casino games. Also, you may be able to improvise. These are only based on my experience, my own intellect and reasoning at playing these games for a very short time (less than a calendar month). But I would say all these techniques had helped me win to good extent, but I ended up losing due to reckless betting, lack of adherence to bet stoppers and most of all due to poor to disastrous emotional intelligence.

Please try to revise/define these terms or techniques by yourself: Bet Auto Stopper, FAST, LAST, Game Set, Optimistic+, Quantum+, Fibonacci Betting, Progressive Betting, Quantum Slice, Ploppy 3:2, Emotional Intelligence, Impulsive Gambing, Compulsive Gambling, Probability, Odds, Ratio, 2 to 1, Even Payout, 2x,

Few Accessories and Trackers

Unless you have got hold of some software application (or created one by yourself) or are fine at using excel sheets (or just want to rely on your own memory) – You may find the following very interesting additions while playing online games. Remember, few may find it just a pain to maintain all these, You may just use them as per your convenience.

Finger Counter: https://t.ly/mYD3U

The above finger counters may be ideal if you want to keep a count of your sequence number in the current game set. You might also use 2 or 3 finger counters at the same time either on your fingers or placed suitably on a table near you – where you count the sequence of each type or each number.

Playing Sheets https://t.ly/3_Vdz

Playing sheets may let you keep count of your planned bet sequence in quantum+ or in a simple game set. You may create variants of the playing sheet as provided in the above link. I had used this playing sheet for quantum+ with progressive betting style in a wheel of fortune class of game.

Concluding Note

The above explanation is primarily based out of my experience playing on the online skilled gaming and casino site, Parimatch. Parimatch is a fair online betting site and even though it is ‘heavy to load on a pc’ even on a 300mbps internet connection – It has very many games and rooms to give you the flexibility to learn, experiment, play, win (and lose!). Also, the withdrawals are done quite fast. Also, deposit mechanism is very easy. But I cannot say the same about the ‘bonus’. It is best that you stay away from all types of ‘Parimatch Bonuses’. In any case, it is my experience, but you might have had a different experience. But my rating of Parimatch is almost 4 stars out of 5. It is best you have a 500mpbs to 1gbps internet connection to extract maximum out of this site.

Also, the above explanations might help you the most in these games in online casinos. But once you learn the strategy and concepts, you may apply it as per your need across games and across casinos.

Roulette Class of Games
Lightning Roulette, Gold Roulette, Galaxy Roulette

Baccarat Class of Games
Dragon Tiger, Cricket War, Football Studio

Wheel of Fortune Class of Games
Spin-a-Win, Mega Wheel, Music Wheel

“I play to win and if it looks like I've lost, its only because it’s not over yet.”

Typical Gambling Disclaimers (Credits to the Internet)

· “Gambling can be addictive. Please play responsibly.”

· “The odds of winning at gambling games are not in your favour.”

· “Gambling involves risk. Please only gamble with funds that you can comfortably afford to lose.”

· “Gambling is a form of entertainment. Set a budget, stick to it.”

· “Bet with your head, not over it. Gamble responsibly.”

[Updated in October 2024] Sumith Kumar Puri is a Software Engineering Leader with ~19yrs of Experience in Software/IT Product Development. He is an Ex-Yahoo, Symantec, Huawei, Oracle*. He is also a Senior Member, IEEE and Senior Member, ACM. He completed his Xth, XIIth (CS) from NPS, Kochi and B.E. (CSE/ISE) from SRSIT, Bengaluru. He has completed Executive (PG Level) Programs, respectively, from IIT-Roorkee and IIM-Kashipur. He has won multiple recognitions in Programming, IQ, Hackathon, Creativity, Startup & Blogathon contests held by Google, Microsoft, Accenture, Github, Techgig, Societe Generale and Xebia. His last position in the industry was Java Practice Leader at Enterprise Minds, Bengaluru, India.

Winning in Online Skilled Gaming… Err… Gambling! [Part 03]

2023-12-23T10:59:00.011+05:30

Idea of Bet Auto Stopper

Now, nobody likes to lose when they are on a winning streak. Once you have learned to use fibonacci style of betting – you might be winning very often. You might slowly to see that the cash you deposited would have increased to about 125%, 150% or even more. You might have started to think about paying off that small loan, paying off an emi or even better…. about buying a two-wheeler. But that’s when your dreams may come down crashing. The reason more often that not being reckless and non-safe usage of fibonacci. This is where I can come in with the concept of a ‘bet auto stopper’. Like I said earlier, we are all bound by realms of reality. Now, you have to decide a game set. Game Set, defined by me, is a series of bets placed using fibonacci playing style until the time that you win. In our above example, let us see what is going to happen if you are on a prolonged losing streak, using fibonacci, by placing bets on a 2 to 1 field.

Suppose you originally start with a deposit of INR 20,000 in the online casino and then the money in your account went up to 29,000 using intelligent bets placed using fibonacci and a bit of luck. By now, you have entered that world where you are so sure of this ‘mathematical basis’ that you continue increasing the bet amount, in fibonacci style. This is because the basis for these bets is so strong in your mind, that you are ready to take deadly risks. As shown in the table above, you are going to exhaust all the money in your account. Worse still, you may again and again refill your online casino account – and continue the series of failures, leading to a disaster. This is when I will say Skilled Gaming has moved to Impulsive and Compulsive Gambling.

But it is not going to be your fault. Because of a strong mathematical basis, you will start believing that you will surely win all your money back and go to a positive hand. So, here is where the idea of a ‘Bet Auto Stopper’ in a Fibonacci Game Set, comes to your rescue. It is very tough to implement this in the real world, as this is where your EQ comes into the picture. You need to be mentally strong and emotionally intelligent, to stop the bets beyond the safe point. It might be ok for you to take make that one last bet in your danger zone, but you should be mature to stop it beyond that point.

The best or rather the worst part is - that once you stop using ‘bet auto stopper’, you will see that as if out of magic, the winning number is exactly matching your bet sequence. It is as if the game is mocking you. But that is where being emotionally intelligent comes into the picture, you have to ignore all of these and continue onto your next game set, possibly after a short break. You will observe that if you are playing regularly, on a few days or at few intervals of time – you enter into this very often. This is because your mind has now got used to winning and it is not accepting that you lost. Because the only reasoning for this loss, that you did not have enough money to continue your bets. So, that is where you have to learn to operate within the ‘realms of reality’. Slowly n Steadily, you will see that you are able to keep your winnings and win a small to moderate amount on a daily basis at online casinos.

[Note] Before we continue, remember that Fibonacci Style works best for 2 to 1, 3x payouts or more. Progressive Style where you may double or more the bet amount in the subsequent game works best for even payout or 1x win amount.

Quantum+ Algorithm (My Creation)

Now when times are bad just because of you did not play to the idea of a bet auto stopper or you are just having a bad day, when you are continuously losing even with safe bets, I have devised a low bet, low profit variation called as Quantum+ Algorithm. I am the proud creator of this algorithm. Remember, you need to have an analysis of currently on game and find out the statistics of the winning numbers before you start off on the Quantum+. This algorithm involves placing bets for a specific quantum of bets. Quantum+ will allow you to place safe bets within a given quantum of time/game set. You have to adapt this algorithm across games, using your own intellect and try to improvise.

In the previous game set description in the previous, you would usually continue to bet until either you have won or reached a bet auto stopper or possibly, until you run out of cash. Now, Quantum+ would require you to bring down the bet amount to very safe limits and continuously bet in a given quantum (adaptation of game set) and each bet is a slice in the quantum. Quantum+ Algorithm will really work well on 5x, 10x, 15x type of returns and may also allow you to autoplay.

Now, you see this is just like a robot on auto play and you are not too much bothered about game dynamics that happen during the course of this quantum. You are more emotionally detached, believing in the algorithm – because of the time that you had spent on analysis at the beginning on what to bet and the quantum slices. In the above quantum set, you can see that by winning only 6/20 times, which is just 30% - the player has a total win of 1250. But this may not be the outcome always. It might read lost across the table. Hence, you have to combine a soft bet auto stopper and observe carefully and either restart of adopt a different approach as per your own discretion and analysis.

Winning in Online Skilled Gaming… Err… Gambling! [Part 02]

2023-12-23T04:20:00.020+05:30

Advise for Intermediate+ (Mid-Level Players)

Start with More Money

It is better to start with more money. This is something that you would have already realized if you have played the game for some time. This is also because of your confidence of having won or equalled your beginner or basic level of bets/amounts. It is better to start off with deposits of mid-level money. I will define mid-level as INR 20,000 to INR 40,000. As described earlier, as a player and also based on your financial status, you have to decide what amount corresponds to your absolute beginner, beginner, intermediate and intermediate+ levels.

Illusion of a Perfect Technique

By now, you may have understood and won with a few techniques that helped you win at the beginner level. It may also because of your Beginner’s Luck. But as you proceed, you might grow overconfident that you have mastered a technique or a set of techniques. This illusion is harmful, as you may get stuck with this thought and end up continuously bet without limits and finally exhaust all the cash that you bought to the table. Remember, as in every thing that we do in the world, we keep on mastering/polishing/improvising on technique. Also, we try to adapt to the current dynamics of the game, host or simply the game day.

Limitations of Money in Pocket

Unless your great distant relative left you an unlimited wealth in inheritance - Remember, you have limitations on the money that you have or that you can budget for your gaming. This reality should be a driving force in all that you do. It does not mean that you should constantly have this thought in your mind – Only that you should plan your finances correctly and work within the realms of that reality. Like, you plan a percentage of your salary or pay or savings for playing this game and then plan how much you plan to or can spend per day – Try to stick to the limits and then you will see that you will be able to achieve overall

Set your Safe Money Boundaries

Remember that when we discuss later about a single game, game set, series of game sets, game day – you need to very rigidly and maybe display it as a banner where yo u can see it – like an animated marquee on your 2^nd monitor or a poster next to your game workstation or game seat. In any case, it has to be registered that you should not go beyond set safe money boundaries per set. If you can follow this correctly and practice in throughout your game playing, you will definitely succeed. Else, You will end up as a Cat (You, Predator) that chased a Mouse (Game Win, Hunt) long enough, before it was hit hard by a Moving Vehicle (Exhausted Deposit, Injured) or in other words Eaten by a Dog (Totally Run Out of Money, Large Predator).

Techniques of Game Playing

Basics of Fibonacci – Explanation of Never Lose

(Applicable to Roulette, Spin The Wheel, Baccarat Class of Games)

This is a known basis to many who have played online casino games. For applications of other techniques, you have to first understand and learn to apply this basic technique. Let us start with Fibonacci Series – 0,1, 1, 2, 3, 5, 8, 13, 21, 34, … This was created by the European Mathematician, Liber Abaci at the beginning of the 13^th Century.

Now, how will this help you in placing your bets?

Let us start with any on the casino games, that typically pay 2 to 1 for a specific bet/field. If we were to bet without fibonacci, you may go on to bet as follows, typically.

You can very easily find out that the new player has ended up with an overall loss of 100 even after winning 2 times during the course of the above game set. In normal course of things, most player would start betting small and then increase only slightly, if they keep losing. But the joy of victory, will lead to an increase in the betting amount. And this patten follows, as the user wins or loses. Usually, in this pattern, the player will bet arbitrarily and just rely solely on luck (possibly some analysis of the board/last winning numbers) and will eventually lose. Remember, this is not true for people who are really lucky, as most of these are fair game of chance, not just skill. But being in such luck, continuously, is almost like being blessed by an angel.

The magic of fibonacci can be seen above that the player has ended with winnings of 400 overall, after winning only the last bet in the game set. Driven by a strong mathematical basis, the user has ‘no fear’ to keep increasing the bet, even though he is losing. You see that every time by following a ‘next fibonacci term increase’ in the bet, for a 2 to 1 payout bet, the player has managed to win 400. So, theoretically, this is like a ‘never lose’ betting style. Once you get used to this, you will enjoy the winnings that you keep getting bet after bet. Slowly, you will start realizing that you are going to ‘never lose’. Once you have reached a sizeable win, you start off from the basic bet again in the next cycle or next game set.

But it does come with few dangers, including grave ones. If you continue recklessly on this path, without a mechanism to stop sanely, you will lose all your winnings and may even end up being bankrupt, when combined with compulsive gambling. Also, once you are on the losing streak, you may even end up into impulsive moves and totally lose the plot. Hence, I need to emphasize that while IQ is important, but EQ is far more important.

Winning in Online Skilled Gaming… Err… Gambling! [Part 01]

2023-12-23T03:42:00.013+05:30

My Skilled Gaming Background

Recently, I started off on Skilled Games which are variants of Roulette, Wheel of Fortune and Baccarat. It was only by chance that I started playing these games. While betting on India for the Cricket World Cup Final on a betting site, I first came across these games. Well, India Lost the final and the World Cup Ended… But I started off on a new journey into the world of Online Skilled Gaming… Err… Gambling.

So, Whether It is Skilled Gaming or Gambling, it entirely depends on what is your central thought process while playing the game. The dictionary would define most of these games as a Game of Chance. But believe me, even though the outcome of a single roulette spin or mega wheel spin is a matter of chance, in a fair casino – Playing these games involves a lot of strategy, technique, mathematical basis and challenges the intellect. Hence, the term Skilled Gaming is a fair and eventual usage for folks involved in playing this game for longer time frames/durations.

By the way, In this my first month of playing these games, I have already lost USD 1900 (~INR 160,000). But I am sure I will be able to win this back and maybe even more. So, that is my background as a Skilled Gamer/Gambler as I write this article. So, I cannot boast of being a big winner as I share my techniques and experience. But I am sure that people who are beginning to play these skilled games, will be able to learn from my mistakes. This might help them to win and retain their winnings right from the beginning. Remember, the important word there… ‘Retain’.

Before we begin, you need to first understand the two main elements, while playing games in an online casino. Remember, being great in strategy, intellect, analysis, technique may help you to win – but if you lack in controlling your impulses or try to go far beyond set safe boundaries you may not be able to keep your winnings. Ultimately, without a balance of the below two – where the second being very important to make sure that you do not end up losing big including losing all your winnings – you will not be able to make a positive impact. In my case, I strongly believe my lack of the second point, did not let me retain my winnings. You have to understand that it is very easy to get swayed away during the dynamics of game playing, but you must ensure that before you begin you make a pact with yourself on your boundaries and limits and stick to it, without fail.

Intelligence Quotient (IQ)

An intelligence quotient is a total score derived from a set of standardised tests or subtests designed to assess human intelligence. The Intelligence Quotient (IQ) is a measure of a person's intellectual abilities in relation to others.

Emotional Quotient (EQ)

The ability to understand and control your own feelings, and to understand the feelings of others and react to them in a suitable way. Emotional intelligence is defined as the ability to perceive, use, understand, manage, and handle emotions.

Advise for Beginners (Entry Level Players)

Start with Small Amount

It is the best that you start with a small amount. This will help you to learn the techniques via practice, it will reduce the risk, increase chance of winnings and teach you the basics of emotional control. If I were to specify in the INR context, I will consider the following as a very small amount: INR 2000-5000. Very soon, depending on your interest, passion, reasoning, gaming experience – you may realize that you create your own small amount boundaries, like from about INR 5000-15000. But control your urge to continuously keep depositing and trying your chances to win, without actually understanding the techniques and mathematical basis.

Impulsive Gambling

At the beginning, you may start off on randomly placing bets on numbers or make arbitrary choices, betting amounts based on your basic analysis of the game. This is true for every individual who starts off on these games. But as time goes on, It would be in best interest that you refrain from impulsive gambling, that is you do not keep betting based on your current bursts of energy. Even thought, at times, this may yield you some money – as it is a game of chance. But, believe me, In the long run it will be disastrous and not yield anything and you may end up losing huge amounts. You have to play to a plan, a strategy using techniques described here. Your intellect and experience may hep you in improvising and finding variants of the techniques described in this article.

Compulsive Gambling

Another thing is the urge to continue playing these games. The strong urge to play these games continuously, day in and day out, is a very normal human response. This may affect your normal student day or work day. Hence, It is best to plan your time to play these games. It will also give you some reserved fun time, something that challenges your intellect outside of your study/work and a judicial use of your analytical/mathematical/reasoning abilities. I used to play after my work day, at late night or early morning. This was a good way to end the day. But I also had urges to play this throughout the day, which I usually did on weekends.

Hydration and Tea Breaks

The excitement created by these games may lead to increased blood pressure, focussed and long use of monitors while staring at them continuously and deeply, anxiety, mood disorders, dehydration, skipping nature’s calls, disinterest in completing household chores, skipping daily shower, decreased personal hygiene and a host of such other disorderly behaviours. By not indulging in impulsive and compulsive gambling, you might save yourself from many of these problems. Also, you have to make sure you have a bottle of water and tea/coffee in a thermos besides you, if you like to drink tea/coffee. It is better that you take a 5minute to 10minute break every 1 hour or every play cycle or game set to drink water and have tea/coffee, as per your choice. You might also choose to have a tea/coffee cup warmer by the side of your playing device (mobile, tablet or pc). Be warned that the game playing may also lead to an increase in the number of cigarettes you smoke – Please make sure to control this behavior.

Breaks on a Losing Streak

When you are on a losing streak, It is highly advisable that you take a break and move out of the context of the game. You may choose to watch YouTube, Short Film or Social Surf. Try to focus on something out of context – like Animal Kingdom, Comedy, Cartoons, Sports, Current Affairs(!) or Latest Movie Trailers. It is just to get you of that mindset and then you come back to the game, for a new series of game sets. It is also advisable, that when you are on a series of losing streaks, It is better to avoid playing on that day. It is such things that are easier said than done. It is because your loss might takeaway your sleep and hence you may choose to continue playing. These are the things, if mastered, may let you keep your winnings and also, to keep winning more.

Introduction to the ONDC Platform

2023-09-06T14:40:00.001+05:30

Introduction to ONDC

Open Network for Digital Commerce (ONDC) is the new and revolutionary way for digital commerce in India. It provides an open specification and aims to provide more dynamic participation of buyers and sellers, promotes fair competition, aims to increase user choices and fosters further innovation. By providing a platform and open specification, there can be myriad of innovative applications that can be built of top of the ONDC Platform. ONDC itself is built on top of the Beckn Protocol and the IndiaStack.

Read my Earlier Article on Introduction to the Beckn Protocol.

What really is ONDC?

It has to be noted that ONDC is not an application, software or a technology – It is a set of specifications or an open network and associated platforms can be built out of or based on this specification. ONDC is none of the following:

ý Application or Platform
ý Central Intermediary
ý Medium to Digitize Biz
ý Government Regulator

At the same time, ONDC is an open network and a set of open specifications to enable and ease digital commerce.

þ Open Network, Set of Open Specifications
þ Eliminates Need for Central Intermediary
þ Enabler for E-Commerce and Innovation
þ It’s a Market & Community Led Initiative

How ONDC Works?

At the core of its advantages, ONDC goes beyond the current platform centric digital commerce model where the buyer and the seller have to use the same single platform to be digitally visible and do a business transaction. With the help of the underlying protocols in ONDC, ONDC provides an open specification for standardizing cataloguing, inventory management, order management and order fulfilment. This provide multiple options for businesses to be discoverable over the network and conduct business. It will also encourage the use of digital means for business that are not yet on any digital commerce networks. The maximum advantage is bound to be for the small and medium businesses.

As you can observe from the above, sellers from multiple platform can be discoverable via ONDC. Sellers, usually also called Providers in ONDC, techno functionally user the Beckn Provider Platform (BPP). The sellers will use the BPP to acquire orders and for order fulfilment via ONDC. Beckn Application Platform (BAP) allows consumers to discover sellers, place orders and allows them to make payment.

The underlying communication in ONDC happens via the Beckn Gateways, that becomes the backbone for ONDC. Beckn itself is built on top of CORD Network (Central Office Re-architected as a Datacenter). Beckn stands Blockchain Enabled Ecommerce for Knowledge Networks. It is the driving factor underlying ONDC. Beckn Gateways (BG) lie between BAP and BPP to provide all routing infrastructure or the transaction layer. BGs are extremely lean and stateless routing servers. The purpose of this infrastructure to optimize discovery of BPPs by the BAPs. Business wise, They should ensure a fair chance for all active BPPs to be discovered and to sell their goods.

Buyer and Seller Cycle in ONDC

Below, I am also providing a self-explanatory way to explain the Buyer-Cycle and the Seller-Cycle of ONDC. It is more like a Business Process Flow Diagram (Instance) of how a buyer will discover, search, purchase and pay using ONDC. It also shows how a sellers can acquire consumers.

Below is the depiction of the merchant cycle, for a given instance of purchase by a buyer. It shows how the order is fulfilled via logistics providers. In a way, it shows how fairness and competitiveness can be promoted among the buyers and the other members in the chain like logistics providers.

Process for Joining of Buyer and of Seller App

Before I end this article, I would also like to share the process flow for joining of buyer app to ONDC and for joining of sellers to ONDC. Please note this is not related to buyers registering on the buyer app or the sellers on the seller app.

Advantages of ONDC

In the end, we take a look at all the advantages that ONDC brings to the world of digital commerce, from buyer or seller viewpoint and also for the other participants in the transactional or fulfilment cycle.

· Government Backed Initiative (IndiaStack)

· Increased Choice and a Fair Competition

· Democratisation and Decentralization

· Lower Prices / Competitiveness in Pricing

· Efficiency in Logistics and Shipments

· Ensured Data Privacy and Confidentiality

· Support for Micro, Small, Rural Business

· Easier Rollout of Discounts & Promotions

Current Businesses (Buyers/Sellers) on ONDC (Sep 2023)

Buyer Apps – PayTM, Magicpin, SpiceMoney, CraftsVilla

Seller Apps – Meesho, Snapdeal

[ Logistics ] – Ekart, Dunzo, Delhivery

Conclusion

ONDC does present a promising opportunity and with a government backing is all the more trustworthy. It has started off in multiple cities in India. Soon, It will be launched in more cities and towns of India. It is to be seen whether this will take on as the consistent platform of choice for big players or remain merely an advantage for micro, small and medium businesses. In any case, It will continue to foster innovation and there may be multiple platforms that are inspired from ONDC. This may or may not be directly related to digital commerce.

References/Credits To

ONDC-Wikipedia Page
Beckn for Developers
Government of India (PIB)
PayTM Blog on ONDC
Article - Business Std.

Sumith Puri has 18+ years of Experience in Leadership, Conceptualization, Architecture, Design and Development of Software Products and Services. He is an Ex-Yahoo, Symantec, Huawei, Oracle*, Infosys. He is currently the Java Practice Leader at Enterprise Minds, Bengaluru. This article is based on his experience and thoughts from an associated Project related to the Buyer b2b Application/Platform (ONDC/Beckn). He has completed his Executive Programs from each of Indian Institute of Management, Kashipur (Entrepreneurship) and the Indian Institute of Technology. Roorkee (Data Mining & Analytics). He holds the Bachelor of Engineering (Information Science & Engineering) from Sri Revana Siddeshwara Insitute of Technology, Bengaluru.

Introduction to the Beckn Protocol

2023-08-19T04:28:00.001+05:30

Blockchain Enabled Commerce Network (beckn), as the name suggests is a blockchain enabled de-centralized protocol. It provides a specification that enables creation of decentralized networks. It also provides APIs, Data Models, Reference Architectures, Transaction Mechanisms and Global Standards for the purposes of adoption by Digital Platforms.

Usually, a intermediary allows the providers and consumers to come together and interact by providing a centralized mechanism. Beckn provides the providers and consumers to discover, identify and transact with each other without the need for a real central intermediary. It can be thought of as a set of rules that are mutually agreed upon by several platforms that allows their users to discover, order, fulfilment and post-fulfilment activities between each other. This protocol is not specific to any sector, technology or industry. The taxonomy of any application of any industry can be represented using the standard data model of beckn.

The idea was born in Nov 2018 and the first formal transaction actually happened in Sep 2020. The open network went live in Jul 2021. The first open ecommerce network platform, ONDC went live in Dec 2021. Other protocols based on beckn, like DSEP – Decentralized Skills and Education Protocol and DHP – Decentralized Health Protocol were launched in Dec 2021.

The official website of beckn is https://becknprotocol.io/

The beckn ecosystem had consumers and providers. A consumer is the one who will ideally want to place orders for products and services published on a platform that user the beckn protocol API calls to try and fulfil this request. There might be multiple such platform known as beckn application platforms (BAPs). To fulfil these, beckn provides beckn provider platforms or BPPs. BPPs use beckn protocol for purposes of discovery, ordering, fulfilment and post-fulfilment.

beckn ecosystem has multiple consumer platforms and provider platforms, which talk to each other via beckn protocol. This communication is facilitated via a open registry. This registry acts as the public key infrastructure (PKI) that stores public keys, endpoints of all participants of the network. The sender digitally signs the messages using their private keys and the receiver looks up the public key of the sender on the registry to digitally verify the signature. Hence, this registry is the trust infrastructure for this inter-platform communication.

The below diagram shows the beckn ecosystem architecture. The first 2 layers are the ones implemented by an organization who want to provide the server side applications for the consumers and the providers. The last 2 layers are the actual specification and support for an entity to get certified to join the network. Every entity that wants to be part of the network, must be part of one or more of the layers listed in the left column.

In the very middle of the diagram is the actual infrastructure and security that transforms beckn compliant platforms into actual live transacting entities in an open network.

Some of the actual applications or networks formed out of beckn include the Kochi Open Mobility Network and the Open Network for Digital Commerce (ONDC). beckn holds great promise across industries in terms of cost reduction, ease of joining, decentralized transactions, easy interoperability and an ability to build more innovative applications.

Apache Kafka - Java Producer & Consumer Example (Kafka v3.4 on Windows 10)

2023-07-05T15:41:00.006+05:30

Introduction

This is Part-2 of a 2-Part articles series on Running Apache Kafka Server, Configuring Kafka Topic, and Creating a Core Java Based Kafka Consumer, as also a Core Java Based Kafka Producer. All this is demonstrated step-by-step example. All of this is for Java v8.0, Apache Kafka v3.4 on Windows 10. Part-1 focussed on Kafka Consumer and Kafka Producer from the Command Line. This article focuses on the Core Java counterparts. It is important that the reader reads the Part-1 of the article, completes the example so that the reader has a basic foundation in Kafka. This article also provides the Maven Dependencies required to create, build and run Apache Kafka Consumers and Producers. Finally, It shows the code sample to run the Consumer and Producer Thread. The code sample is straightforward for an Intermediate+ Java Developer, hence the explanations is omitted for the code.

Pre-Requisites

1. Install Java//JRE (v8.0 is used in this Example)

2. Install Apache Kafka 3.4.0 from the Given Link

3. Set Java Classpath> Set JAVA_HOME Correctly
4. UnZIP/UnTAR Apache Kafka Downloaded in (2)

5. Use a Text Editor like [Notepad++] for Editing

6. Eclipse IDE (Or Others) to Create, Run & Test

Before You Begin, Read my Article #1 in this Series at : https://rebrand.ly/skp-ts-kafka-v3-win

Maven Project (Eclipse) and Dependencies

Create a Simple JAR archetype Maven Project in Eclipse (Or IDE of Your Choice). Add the following dependencies in your pom.xml. Make Sure that your Compiler Version is Java 8.0.

 <dependencies>  
         <!-- This is the Core Library Containing the Classes We will Use -->  
         <dependency>  
             <groupId>org.apache.kafka</groupId>  
             <artifactId>kafka-clients</artifactId>  
             <version>3.2.1</version>  
         </dependency>  
         <!-- The Kafka Client Libraries use the slf4j Logger, So we Need to Add   
             This as a Dependency so that the Required Classes are Present in Our   
             Classpath for the Kafka Client Libraries to Use -->  
         <dependency>  
             <groupId>org.slf4j</groupId>  
             <artifactId>slf4j-api</artifactId>  
             <version>1.7.36</version>  
         </dependency>  
 </dependencies>

Developing the Java Producer

1. Make Sure you know the Topic Name

2. Find out Your Bootstrap - Server Port

3. Refer Javadoc for KafkaProducer Obj.

4. Also, for Producer & ProducerRecord

Code for Java Producer (Tested on Kafka v3.4 on Windows 10)

 /**   
  *    Author @sumith.puri (Addl. Ref: https://www.sohamkamani.com/java/kafka/)  
  */   
 package com.kafka.poc.producer;  
   
 import java.util.Properties;  
   
 import org.apache.kafka.clients.producer.KafkaProducer;  
 import org.apache.kafka.clients.producer.Producer;  
 import org.apache.kafka.clients.producer.ProducerRecord;  
   
 public class KafkaPoCProducer implements Runnable {  
   
     private static final String TOPIC = "test";  
     private static final String BOOTSTRAP_SERVERS = "localhost:9092";  
   
     @Override  
     public void run() {  
   
         produce();  
     }  
   
     private void produce() {  
   
         // Create Configuration Options for our Producer and Initialize a New Producer  
         Properties props = new Properties();  
         props.put("bootstrap.servers", BOOTSTRAP_SERVERS);  
   
         // We Configure the Serializer to Describe the Format in which we Want To  
         // Produce Data into our Kafka Cluster  
         props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");  
         props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");  
   
         // Since we Need to Close our Producer, We can use the try-with-resources  
         // Statement to create a New Producer  
         try (Producer<String, String> producer = new KafkaProducer<>(props)) {  
   
             // Here, We Run an Infinite Loop to Send a Message to the Cluster Every Second  
             for (int i = 0;; i++) {  
                 String key = Integer.toString(i);  
                 String message = "Watson, Please Come Over Here " + Integer.toString(i);  
   
                 producer.send(new ProducerRecord<String, String>(TOPIC, key, message));  
   
                 // Log a Confirmation Once The Message is Written  
                 System.out.println("Sent Message " + key);  
                 try {  
                     // Sleep for a Second  
                     Thread.sleep(1000);  
                 } catch (Exception e) {  
                     break;  
                 }  
             }  
         } catch (Exception e) {  
             System.out.println("Could not Start Producer Due To: " + e);  
         }  
     }  
 }

Developing the Java Consumer

1. Make Sure you know the Topic Name

2. Find out Your Bootstrap - Server Port

3. Refer Javadoc > KafkaConsumer Obj.

4. Also, for Consumer, ConsumerRecord

5. Refer AutoCommit/Acknowledgement

Code for Java Consumer (Tested on Kafka v3.4 on Windows 10)

 /**   
  *    Author @sumith.puri (Addl. Ref: https://www.sohamkamani.com/java/kafka/)  
  */   
 package com.kafka.poc.consumer;  
   
 import java.time.Duration;  
 import java.util.Arrays;  
 import java.util.Properties;  
   
 import org.apache.kafka.clients.consumer.ConsumerRecord;  
 import org.apache.kafka.clients.consumer.ConsumerRecords;  
 import org.apache.kafka.clients.consumer.KafkaConsumer;  
   
 public class KafkaPoCConsumer implements Runnable {  
   
     private static final String TOPIC = "test";  
     private static final String BOOTSTRAP_SERVERS = "localhost:9092";  
   
     @Override  
     public void run() {  
   
         consume();  
     }  
   
     private void consume() {  
   
         // Create Configuration Options for our Consumer  
         Properties props = new Properties();  
   
         props.setProperty("bootstrap.servers", BOOTSTRAP_SERVERS);  
         // The Group ID is a Unique Identified for Each Consumer Group  
         props.setProperty("group.id", "my-group-id");  
   
         // Since our Producer uses a String Serializer, We need to use the Corresponding  
         // Deserializer  
         props.setProperty("key.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");  
         props.setProperty("value.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");  
   
         // Every Time We Consume a Message from kafka, We Need to "commit", That Is,  
         // Acknowledge Receipts of the Messages.... We Can Set up an Auto-Commit at  
         // Regular intervals, so that this is Taken Care of in the Background  
         props.setProperty("enable.auto.commit", "true");  
         props.setProperty("auto.commit.interval.ms", "1000");  
   
         // Since We Need to Close our Consumer, We can Use the try-with-resources  
         // Statement to Create It  
         try (KafkaConsumer<String, String> consumer = new KafkaConsumer<>(props)) {  
   
             // Subscribe this Consumer to the Same Topic that we Wrote Messages to Earlier  
             consumer.subscribe(Arrays.asList(TOPIC));  
   
             // Run an Infinite Loop where we Consume and Print New Messages to the Topic  
             while (true) {  
                   
                 // The consumer.poll Method Checks and Waits..For Any New Messages To Arrive For  
                 // The Subscribed Topic in case there are No Messages for the Duration Specified  
                 // In the Argument (1000 ms In this Case), It returns an Empty List  
                 ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(1000));  
                 for (ConsumerRecord<String, String> record : records) {  
                     System.out.printf("Received Message: %s\n", record.value());  
                 }  
             }  
         }  
     }  
   
 }

Create the Java Application to Demo Kafka Producer & Consumer

 /**   
  *    Author @sumith.puri (Addl. Ref: https://www.sohamkamani.com/java/kafka/)  
  */   
 package com.kafka.poc.app;  
   
 import com.kafka.poc.consumer.KafkaPoCConsumer;  
 import com.kafka.poc.producer.KafkaPoCProducer;  
   
 public class KafkaPoCApp {  
   
     public static void main(String[] args) {  
   
         Thread cThread = new Thread(new KafkaPoCConsumer());  
         cThread.start();  
   
         Thread pThread = new Thread(new KafkaPoCProducer());  
         pThread.start();  
   
     }  
 }

Run the Above Application in your IDE or Command-Line.

Typical Output from Running the Kafka Producer Consumer PoC

The next article in this series will be the Spring Boot Kafka Consumer Producer Integration that is planned to be used in a real world Product. It will be used for Asynchronous Notification Service and will also provide further information on Failure Recovery, Acknowledgment, Ordering, Scalability, Fault Tolerance of Apache Kafka for Enterprise Software Development Needs.

Starting Apache Kafka on Windows 10 (Kafka v3.4)

2023-07-04T01:18:00.006+05:30

Introduction

This is Part-1 of a 2-Part articles series on Running Apache Kafka Server, Configuring Kafka Topic, and Creating a Kafka Consumer, as also a Kafka Producer. All this is demonstrated step-by-step example that works from the Command Line. All of this is for Apache Kafka v3.4 on Windows 10.

Pre-Requisites
1. Install Java//JRE (v8.0 is used in this Example)

2. Install Apache Kafka 3.4.0 from the Given Link

3. Set Java Classpath> Set JAVA_HOME Correctly
4. UnZIP/UnTAR Apache Kafka Downloaded in (2)

5. Use a Text Editor like [Notepad++] for Editing

Version 3.4.0

Apache Kafka Version 3.4.0 was Released on Feb 7, 2023, This article specifically is for the Kafka Version (2.13-3.4.0).

For Purposes of this Article, I use {KAFKA_HOME} as the windows folder where Kafka was installed.

Step-By-Step Guide

0. Configure Zookeeper (Data Directory)

Create a folder to hold Zookeeper Data by modifying the file zookeper.properties (File is Located under {KAFKA_HOME}/config/). Create a Folder named zk-data (or as per your wish). In my case, I created this under {KAFKA_HOME}. You may then modify your properties file as show in the image below. Modify your dataDir to point to the newly created folder.

0. Configure Kafka (Kafka Logs)

For the purpose of kafka logs, you can create a folder with the name kafka-logs. In my case, I created this under {KAFKA_HOME}. You may then modify your properties file as show in the image below. The property to be modified is log.dirs in server.properties that should now point to the newly created folder.

1. Starting Zookeeper

First, Zookeeper has to be started using the following command.

zookeeper-server-start.bat ..\..\config\zookeeper.properties

2. Starting Kafka Server

Next, we will start the Kafka Server using the following command.

D:\kafka_2.13-3.4.0\bin\windows>kafka-server-start.bat ..\..\config\server.properties

3. Creating a Test Topic
Create a Kafka Topic to test out the Kafka Installation using the following command.

D:\kafka_2.13-3.4.0\bin\windows>kafka-topics.bat --create --bootstrap-server localhost:9092 --replication-factor 1 --partitions 1 --topic test

The above is an updated way to create topics in Kafka. In earlier versions of Kafka (Kafka v2), the suggested way to create topics was directly via Zookeeper. From v3, It has changed to create topics via Brokers.

(Cited from StackOverflow)

For version 2.* you have to create the topic using zookeper with the default port 2181 as a parameter.

For the version 3.* the zookeeper is not any more a parameter, you should use --bootstrap-server using localhost or the IP adresse of the server and the default port 9092.

Documentation

4. Create Kafka Producer

kafka-console-producer.bat --broker-list localhost:9092 --topic test

5. Create Kafka Consumer

kafka-console-consumer.bat --bootstrap-server localhost:9092 --topic test --from-beginning

------

Next in this series of Articles will be the demonstration of a Core Java Kafka Producer and Consumer followed by an article on Spring Boot based Kafka Integration.

My GitHub Repo #25 : Tokyo

2023-01-27T17:12:00.001+05:30

Code Samples for [Algos & DS, OOPs, Lambdas]
MIT License, Copyright (c) 2018-19, Sumith Kumar Puri
https://github.com/sumithpuri

GitHub Link : https://rebrand.ly/skp-gitrepo-25

[Java] Problem : Changes in Usernames (HackerRank)
[Java] Problem : Active Traders (HackerRank)
[Java] [ FP ] : Functional Programming & Lambdas (TechGig)
[Java] [OOPs] : Object Oriented Programming (TechGig)
[Java] Problem : Monkeys in the Garden (TechGig)
[Java] Problem : AutoComplete Using Trie Data Structure
[Java] Problem : Longest Palindrome in String

Project Codename	Tokyo
Blog Post URL	http://www.techilashots.blog/2015/09/introduction-to-complex-event.html
Blog Short URL	Problem : Usernames Changes ( HackerRank Problem ) Problem : Active Traders (HackerRank) [ FP ] : Functional Programming & Lambdas (TechGig) [OOPs] : Object Oriented Programming (TechGig) Problem : Monkeys in the Garden (TechGig) Problem : AutoComplete Using Trie Data Structure Problem : Find the Longest Palindrome in Given String
Package Prefix	me.sumithpuri.github.tokyo
GitHub URL	https://github.com/sumithpuri/skp-winter-code-nights-tokyo
Contact E-Mail	code@sumithpuri.xyz
Contact Number	+91 9591497974 (WhatsApp, Viber, Telegram)
Historical	✅ Started this Movement of 1000s of Lines of Java / J2EE* Code to GitHub ✅ Was a Senior Software Architect (Java/J2EE) in Manila, 2018 (At Start) ✅ Named this Initial Code Journey as [ Manila Code Marathon - 2018* ] ✅ Code Is Non-Proprietary and Non-Copyright from my Work Experience. ✅ Was Back to Bangalore, Named as [ Bangalore Code Nights - 2019. ] ✅ Added More Code under [ -20 Days of Code in Benglauru- ] in 2020 ✅ Celebration of Java/Java EE Code as Java Turned 25 in the Year ~ 2020!

My GitHub Repo #24 : Tripura

2023-01-27T12:46:00.004+05:30

Code Samples for [Spring - ORM]
MIT License, Copyright (c) 2018-19, Sumith Kumar Puri
https://github.com/sumithpuri

GitHub Link : https://rebrand.ly/skp-gitrepo-24

[Completed Brainbench Spring 2.x Certification - India Top 10 - 3.08/5]

[Modified and New Samples Based out of the Book - 'Spring In Action' ]

Project Codename	Tripura
Certificate URL	https://rebrand.ly/skp-bb-spring-certificate
Certification/Topic	Brainbench Spring 2.5 Certification (ORM)
Package Prefix	me.sumithpuri.github.tripura
GitHub URL	https://github.com/sumithpuri/skp-mini-marathon-tripura
Contact E-Mail	code@sumithpuri.xyz
Contact Number	+91 9591497974 (WhatsApp, Viber, Telegram)
Historical	✅ Started this Movement of 1000s of Lines of Java / J2EE* Code to GitHub ✅ Was a Senior Software Architect (Java/J2EE) in Manila, 2018 (At Start) ✅ Named this Initial Code Journey as [ Manila Code Marathon - 2018* ] ✅ Code Is Non-Proprietary and Non-Copyright from my Work Experience. ✅ Was Back to Bangalore, Named as [ Bangalore Code Nights - 2019. ] ✅ Added More Code under [ -20 Days of Code in Benglauru- ] in 2020 ✅ Celebration of Java/Java EE Code as Java Turned 25 in the Year ~ 2020!

My GitHub Repo #23 : Sikkim

2023-01-27T12:30:00.003+05:30

Code Samples for [Spring - Web Services]
MIT License, Copyright (c) 2018-19, Sumith Kumar Puri
https://github.com/sumithpuri

GitHub Link : https://rebrand.ly/skp-gitrepo-23

[Completed Brainbench Spring 2.x Certification - India Top 10 - 3.08/5]

[Modified and New Samples Based out of the Book - 'Spring In Action' ]

Project Codename	Sikkim
Certificate URL	https://rebrand.ly/skp-bb-spring-certificate
Certification/Topic	Brainbench Spring 2.5 Certification (Web Services)
Package Prefix	me.sumithpuri.github.sikkim
GitHub URL	https://github.com/sumithpuri/skp-mini-marathon-sikkim
Contact E-Mail	code@sumithpuri.xyz
Contact Number	+91 9591497974 (WhatsApp, Viber, Telegram)
Historical	✅ Started this Movement of 1000s of Lines of Java / J2EE* Code to GitHub ✅ Was a Senior Software Architect (Java/J2EE) in Manila, 2018 (At Start) ✅ Named this Initial Code Journey as [ Manila Code Marathon - 2018* ] ✅ Code Is Non-Proprietary and Non-Copyright from my Work Experience. ✅ Was Back to Bangalore, Named as [ Bangalore Code Nights - 2019. ] ✅ Added More Code under [ -20 Days of Code in Benglauru- ] in 2020 ✅ Celebration of Java/Java EE Code as Java Turned 25 in the Year ~ 2020!

My GitHub Repo #22 : Mizoram

2023-01-22T15:03:00.000+05:30

Code Samples for [Spring - Remoting ]
MIT License, Copyright (c) 2018-19, Sumith Kumar Puri
https://github.com/sumithpuri

GitHub Link : https://rebrand.ly/skp-gitrepo-22

[Completed Brainbench Spring 2.x Certification - India Top 10 - 3.08/5]

[Modified and New Samples Based out of the Book - 'Spring In Action' ]

Project Codename	Mizoram
Certificate URL	https://rebrand.ly/skp-bb-spring-certificate
Certification/Topic	Brainbench Spring 2.5 Certification (Remoting)
Package Prefix	me.sumithpuri.github.mizoram
GitHub URL	https://github.com/sumithpuri/skp-mini-marathon-mizoram
Contact E-Mail	code@sumithpuri.xyz
Contact Number	+91 9591497974 (WhatsApp, Viber, Telegram)
Historical	✅ Started this Movement of 1000s of Lines of Java / J2EE* Code to GitHub ✅ Was a Senior Software Architect (Java/J2EE) in Manila, 2018 (At Start) ✅ Named this Initial Code Journey as [ Manila Code Marathon - 2018* ] ✅ Code Is Non-Proprietary and Non-Copyright from my Work Experience. ✅ Was Back to Bangalore, Named as [ Bangalore Code Nights - 2019. ] ✅ Added More Code under [ -20 Days of Code in Benglauru- ] in 2020 ✅ Celebration of Java/Java EE Code as Java Turned 25 in the Year ~ 2020!

My GitHub Repo #21 : Meghalaya

2023-01-22T14:45:00.002+05:30

Code Samples for [Spring AOP ]
MIT License, Copyright (c) 2018-19, Sumith Kumar Puri
https://github.com/sumithpuri

GitHub Link : https://rebrand.ly/skp-gitrepo-21

[Completed Brainbench Spring 2.x Certification - India Top 10 - 3.08/5]

[Modified and New Samples Based out of the Book - 'Spring In Action' ]

Project Codename	Meghalaya
Certificate URL	https://rebrand.ly/skp-bb-spring-certificate
Certification/Topic	Brainbench Spring 2.5 Certification (AOP)
Package Prefix	me.sumithpuri.github.meghalaya
GitHub URL	https://github.com/sumithpuri/skp-mini-marathon-meghalaya
Contact E-Mail	code@sumithpuri.xyz
Contact Number	+91 9591497974 (WhatsApp, Viber, Telegram)
Historical	✅ Started this Movement of 1000s of Lines of Java / J2EE* Code to GitHub ✅ Was a Senior Software Architect (Java/J2EE) in Manila, 2018 (At Start) ✅ Named this Initial Code Journey as [ Manila Code Marathon - 2018* ] ✅ Code Is Non-Proprietary and Non-Copyright from my Work Experience. ✅ Was Back to Bangalore, Named as [ Bangalore Code Nights - 2019. ] ✅ Added More Code under [ -20 Days of Code in Benglauru- ] in 2020 ✅ Celebration of Java/Java EE Code as Java Turned 25 in the Year ~ 2020!

My GitHub Repo #20 : Manipur

2023-01-22T14:04:00.004+05:30

Code Samples for [Spring Transactions ]
MIT License, Copyright (c) 2018-19, Sumith Kumar Puri
https://github.com/sumithpuri

GitHub Link : https://rebrand.ly/skp-gitrepo-20

[Completed Brainbench Spring 2.x Certification - India Top 10 - 3.08/5]

[Modified and New Samples Based out of the Book - 'Spring In Action' ]

Project Codename	Manipur
Certificate URL	https://rebrand.ly/skp-bb-spring-certificate
Certification/Topic	Brainbench Spring 2.5 Certification (Transactions)
Package Prefix	me.sumithpuri.github.manipur
GitHub URL	https://github.com/sumithpuri/skp-mini-marathon-manipur
Contact E-Mail	code@sumithpuri.xyz
Contact Number	+91 9591497974 (WhatsApp, Viber, Telegram)
Historical	✅ Started this Movement of 1000s of Lines of Java / J2EE* Code to GitHub ✅ Was a Senior Software Architect (Java/J2EE) in Manila, 2018 (At Start) ✅ Named this Initial Code Journey as [ Manila Code Marathon - 2018* ] ✅ Code Is Non-Proprietary and Non-Copyright from my Work Experience. ✅ Was Back to Bangalore, Named as [ Bangalore Code Nights - 2019. ] ✅ Added More Code under [ -20 Days of Code in Benglauru- ] in 2020 ✅ Celebration of Java/Java EE Code as Java Turned 25 in the Year ~ 2020!

My GitHub Repo #19 : Assam

2023-01-19T03:00:00.006+05:30

Code Samples for [Spring - Basics, Dependency Injection ]
MIT License, Copyright (c) 2018-19, Sumith Kumar Puri
https://github.com/sumithpuri

GitHub Link : https://rebrand.ly/skp-gitrepo-19

[Completed Brainbench Spring 2.x Certification - India Top 10 - 3.08/5]

[Modified and New Samples Based out of the Book - 'Spring In Action' ]

Project Codename	Assam
Certificate URL	https://rebrand.ly/skp-bb-spring-certificate
Certification/Topic	Brainbench Spring 2.5 Certification (Basics, Dependency Injection)
Package Prefix	me.sumithpuri.github.assam
GitHub URL	https://github.com/sumithpuri/skp-mini-marathon-assam
Contact E-Mail	code@sumithpuri.xyz
Contact Number	+91 9591497974 (WhatsApp, Viber, Telegram)
Historical	✅ Started this Movement of 1000s of Lines of Java / J2EE* Code to GitHub ✅ Was a Senior Software Architect (Java/J2EE) in Manila, 2018 (At Start) ✅ Named this Initial Code Journey as [ Manila Code Marathon - 2018* ] ✅ Code Is Non-Proprietary and Non-Copyright from my Work Experience. ✅ Was Back to Bangalore, Named as [ Bangalore Code Nights - 2019. ] ✅ Added More Code under [ -20 Days of Code in Benglauru- ] in 2020 ✅ Celebration of Java/Java EE Code as Java Turned 25 in the Year ~ 2020!