Mayank Patel
Dec 15, 2023
5 min read
Last updated Jul 12, 2024
You, me, and every entrepreneur and business owners are always looking for a loophole to see how we can save money or where we can cut costs without getting our business affected.
We are all seeking ideas in any way to cut our expenses but with the continued quality and reliability of our products. This is where we all get stuck.
But for every problem, there is a solution. Whether you're a small startup or a well-established company, there is only one idea that can thoroughly change your business.
You all have heard about mydukaan, a simple and affordable online store solution.
mydukaan is a free online store builder platform that helps businesses, especially small and medium-sized enterprises (SMEs), create and manage their online stores easily. It's a simple and affordable solution that requires no technical knowledge and provides all the tools necessary to start selling online quickly and efficiently.
The story begins here.
The Humble Beginnings of Dukaan: From Single Droplet to Cloud Cost Challenge
Dukaan began with a noble mission: to bring the shop to the customer, when the customer cannot go to the shop. This arose from the observation that traditional e-commerce platforms like Shopify and WooCommerce were too complex for non-techie shopkeepers.
Their initial setup was remarkably simple: a single Digital Ocean droplet with 512MB RAM. This single droplet housed the entire backend, including the database.
However, as Dukaan's popularity grew, so did their need for resources. They quickly outgrew the single droplet and had to venture into vertical and horizontal scaling. This initial phase was crucial in demonstrating the demand for their solution and paving the way for their next big step.
With the guidance of their early investors, Dukaan took the leap to AWS. Initially, they utilized AWS Activate Credits (Build Your Startup - AWS Startups) to get started. However, as they started spinning up more and more instances, they realized that their costs were skyrocketing. Their monthly bill soon reached a staggering $70-80k.
This posed a significant problem for Dukaan. Their goal was to provide an affordable solution for small shopkeepers, but their own costs were making it difficult to do so. They needed to find a way to reduce their costs without sacrificing performance or scalability.
This challenge would lead them to their next major decision: transitioning to Bare Metal infrastructure.
Before delving into the solution, you all must know about AWS and Bare Metal in brief
Cost, Performance, and Choosing the Right Fit
In the dynamic world of cloud computing, two prominent options reign supreme: AWS, the behemoth of cloud services, and Bare Metal, the rising star of dedicated hardware. Both offer distinct advantages and cater to different needs, making the choice between them a critical decision for businesses of all sizes.
AWS stands for Amazon Web Services, a comprehensive suite of on-demand cloud computing platforms and APIs provided by Amazon. It offers a vast array of services, including:
Now, AWS introduced eight new Amazon EC2 bare metal instances in October 2023.
Amazon EC2 C7i, M7i, R7i and R7iz bare metal instances are available. Amazon EC2 M7i, C7i, and R7i instances are powered by custom 4th generation Intel Xeon Scalable processors, —available only on AWS — which offer up to 15% better performance over comparable x86-based Intel processors utilized by other cloud providers. Amazon EC2 R7iz instances are the fastest Sapphire Rapids based instances in the cloud with an all-core turbo frequency of 3.9 GHz.
To know more Check out the link: Amazon EC2 bare metal instances
Bare Metal refers to dedicated physical servers rented from a cloud provider. Unlike virtualized environments like AWS, you have exclusive access to the entire hardware resources of the server. This provides several benefits:
Now, let's delve into the key differences between AWS and Bare Metal:
Ultimately, the choice between AWS and Bare Metal depends on your specific needs and priorities.
Carefully assess your workload requirements, budget, and technical expertise before making a decision. For some, AWS's flexibility and scalability might be the perfect fit. Others might find Bare Metal's raw performance and control to be the deciding factor.
Remember, there is no one-size-fits-all solution. By understanding the strengths and weaknesses of each option, you can make an informed decision that empowers your business to reach its full potential.
As you all now know about AWS and Bare Metal, let's get back to the solution.
Dukaan's team understood that their escalating AWS costs were unsustainable. They needed a solution that would provide the necessary performance and scalability without breaking the bank. After careful analysis and consideration, they decided to embark on a bold journey: transitioning their entire infrastructure to Bare Metal servers.
This was a daring move. Bare Metal offered several potential benefits, including:
However, transitioning to Bare Metal also presented some challenges:
Despite the challenges, Mydukaan was determined to find a solution. They meticulously planned and strategized their migration, ensuring a smooth transition with minimal downtime. They also implemented a hybrid approach, leveraging the strengths of both Bare Metal and cloud services.
The results were remarkable. By migrating to Bare Metal, Mydukaan achieved:
Mydukaan's transition to Bare Metal serves as a powerful example of how businesses can overcome cost challenges and achieve significant savings by exploring alternative solutions. Their story demonstrates the importance of careful planning, strategic decision-making, and a willingness to embrace innovation. By embracing Bare Metal, Mydukaan not only saved money but also unlocked a new era of performance, control, and scalability, empowering them to continue their mission of empowering small businesses worldwide.
Inspiration source:
Arpit Bhayani Podcast with Subhash Choudhary, Founder and CTO of Dukaan.
One idea that can change your small business into a giant.
Now, imagine turning your own idea into a top-notch product with the help of Linearloop. This custom software development company can help you navigate every step of your journey, from product design to cloud services. With expertise in:
Linearloop can help you bring your vision to life, ensuring scalability, performance, and cost-effectiveness.
An in-depth Comparison between Kafka and Message Queue
Kafka is a pub-sub tool generally used for message processing, scaling, and efficient handling of large amounts of data.
On the other note, Java Message Service, also known as JMS, is a messaging service created for handling data of more complex systems based on enterprise integration patterns.
Both Kafka and JMS queue are considered as successful solutions and have helped different organizations to communicate effectively through internal teams and servers.
Our primary focus in this article is on Kafka vs java messaging service and how these tools differ from each other in detail.
Kafka is one of the leading distributed streaming platforms that are designed for high-throughput, low-latency data streaming and processing. It was originally developed by LinkedIn and later open-sourced. Explore some of the key features of Apache Kafka:
There are many Traditional Message Queues available in the market. Some of the most popular Message Queues (MQs) are RabbitMQ and ActiveMQ. They are mainly designed for reliable communication between distributed systems. Here are the key features of traditional MQs:
One of the main differences between Kafka and java messaging services is their programming style. JMS runs on imperative programming style, while Kafka has a reactive programming style.
In the case of Kafka, its system arranges messages in the same order as they were sent from the partition level. But, in the case of JMS, such a provision does not exist, so you need to split the messages as needed.
The second factor that proves the main differences between Kafka and java messaging service is the type of messages. JMS queue works on push type where the enterprise can send messages to their customers.
On the other hand, Kafka is a pull type message system in which customers can pull messages from the broker.
In Apache Kafka, you cannot set filters for exact words at the broker level. If you want to set filters, you have to work at the application level in Kafka.
But, when it comes to Kafka vs JMS queue, you can set the filter desired by the JMS message selectors. This functionality reduces the additional steps of application-level filtering.
Kafka enables a simple and easy routing system, while JMS offers quite a complex routing system due to the system integration design.
Messages are stored in Kafka for a specific period regardless of whether customers receive them. In Kafka vs JMS queue, JMS offers a disk or in-memory-based storage facility. And once the message is read, it is permanently deleted.
Apache Kafka does not allow you to queue, if you are considering Kafka vs JMS queue. The Pub-sub model is the only way to send messages. But with a JMS-based system, you can queue messages through its routing system.
Also read: LoopBack vs NestJS: Best Nodejs Server Side Framework of 2024
Apache Kafka allows you to categorize functionality as independently split lugs. This ensures high throughput for Kafka. But, while in the case of JMS-based tools, the splitting is not done sequentially. In the case of JMS-based tools, it leads to throughput output.
Apache Kafka implements a mechanism that allows brokers to decide which message to read first in JMS. JMS uses the first-out approach due to its functionality. The ability and readability options are the important advantage of Apache Kafka, giving it an edge over JMS.
From the above differences between Kafka and java messaging service, it is clear that Apache Kafka is more scalable than JMS. Also, Apache Kafka’s availability is high due to its ability to auto-replicate messages without compromising on simplicity.
Read more: ReactJS Vs React Native: What’s the Difference?
| Feature | Apache Kafka | Traditional Message Queue |
| Architecture | It provides a distributed log-based system with brokers, producers, and consumers. | It provides point-to-point and publish or subscribe models. |
| Data Storage | Apache Kafka has persistent log storage so that data can be retained for a configurable time. | Message Queue has in-memory or persistent storage that can’t be retained for a long time. |
| Message Communication | The consumers read from topics and offset management for each consumer group. | It has an acknowledgement mechanism for message consumption. |
| Performance | It provides high-performance throughput and low latency that is perfect for handling large-scale data streams. | It provides good performance but it often struggles with very high throughput scenarios. |
| Scalability | It is horizontally scalable and it can handle thousands of partitions across multiple brokers . | It is scalable but it does require more effort to achieve horizontal scalability. |
| Reliability | Apache Kafka offers strong durability guarantees with data replication and fault tolerance. | Traditional Message Queue offers reliability through acknowledgements and persistent storage. |
| Use Cases | It can be used for real-time data processing, event sourcing, log aggregation, and stream processing. | It can be used for task queues, background job processing, and simple event distribution. |
| Ease of Use | Apache Kafka has higher complexity which requires an understanding of partitions, brokers, and offset management. | Traditional Message Queue has simpler setup and usage which comes with more intuitive for straightforward messaging tasks. |
| Maintenance | It requires more effort to manage clusters, monitor brokers, and handle partition rebalancing. | It is easier to maintain with built-in tools for monitoring and management. |
| Community and Support | It has a large community and extensive documentation that is widely adopted in the industry. | It has strong community support and it is well-documented that is widely used. |
| Learning Curve | It has a hard learning curve due to complex architecture and configurations. | Traditional Message Queue has an easy learning curve and it is more user-friendly. |
| Durability | Apache Kafka is Highly durable with configurable retention policies and multiple replication strategies. | It is durable depending on the configuration. But its durability is less than Kafka. |
| Throughput | It has very high throughput which is suitable for handling millions of messages per second. | Message Queue has Moderate to high throughput depending on the implementation and setup. |
| Latency | Apache Kafka is popular because of its low latency and it is designed for real-time streaming data. | Usually, it has low latency but it can increase due to high loads. |
Both Kafka and JMS are prominent message management solutions. However, it is always better to use more advanced platforms and architectures like Kafka.
Before deciding Kafka vs JMS queue and which product to use, it is important to consider the suitability of each use case.
Mayank Patel
Aug 31, 20213 min read
