Julien DeFrance

I'd recommend you check out Recurly. They are one of the leading solutions in the recurring billing space, but also support one-off orders. Recurly answers most common e-commerce use cases, will also give, out of the box, rich plan/subscription management functionalities to all the teams within your organization. They also come with great documentation, and SDKs, which from an Engineering standpoint, made it a very enjoyable pilot to work on, at the time. You'll also get great visibility/BI/analytics for free, allowing you to monitor the health of your business. Your Finance team will also get all of the data that they want. Without having you write any line of code. As you did touch upon integrations, they integrate with major payment gateways, including their own, support webhooks, integrate with Segment and therefore any tool that integrates with Segment, which makes this solution one of the most extensible one you'll find. Eg. Triggerring some Email Marketing "journey" (workflow) in AutoPilotHQ based on certain events.

Rails is an easy framework to pick up, and you'll get to love all of the magic it does for you. Some of that can be a little confusing at first but once you've got acquainted, this is part of the productivity Rails offers as opposed to other languages or frameworks that sometimes tend to require developers to waste a ton of valuable time setting up their own boilerplate when starting to work on a new project. More pragmatically, Rails is still extremely popular at both startups and at large companies, you can use it to power web applications, or backend APIs, and this will be extremely valuable on your resume. There also is a very large/rich set of libraries (called gems) that will allow you to focus on your actual project/product, rather than rebuilding what already exists. I'd recommend you go with the latest versions of Ruby (3.0) and Rails (6.1.1) so you are from the get-go learning them in their most current form.

The Amazon Elastic Search service will certainly help you do most of the heavy lifting and you won't have to maintain any of the underlying infrastructure. However, elastic search isn't trivial in nature. Typically, this will mean several days worth of work.

Over time and projects, I've over the years leveraged another solution called Algolia Search. Algolia is a fully managed, search as a service solution, which also has SDKs available for most common languages, will answer your fuzzy search requirements, and also cut down implementation and maintenance costs significantly. You should be able to get a solution up and running within a couple of minutes to an hour.

MySQL's very popular, easy to install, is also available as a managed service across most popular cloud offerings. The support/default tooling (such as MySQL Query Workbench) certainly is a little more baked than what you'll find for Postgres.

https://dev.mysql.com/downloads/workbench/

MySQL's very popular, easy to install, is also available as a managed service across most popular cloud offerings. The support/default tooling (such as MySQL Query Workbench) certainly is a little more baked than what you'll find for Postgres.

https://dev.mysql.com/downloads/workbench/

Ruby on Rails is far from being dead. In fact, this is a very popular choice in early-stage startups, given how fast and easily it allows them to launch their product and iterate on it.

Even at more mature companies, you'll still find a ton of opportunities. Not for internal tools or legacy codebases, but for actual production workloads: web apps, APIs, etc...

Some may tell you that Ruby doesn't scale, but is it really Ruby that doesn't scale, or the code they wrote?

Languages have trends. Sometimes, recruiters will try to take you one way or another to meet their own agenda. Don't always listen to what you hear. Long live Ruby! Long live Rails!

In the early days, people would set up their own Elastic Search clusters and have troubles maintaining it, keeping it secure, also this required a lot of manual work to get the data in, keep it current, query it... etc. A couple of years ago AWS came up with AWS Elastic Search Service, which reduced some of this overhead. My previous teams and I went through all of these different stages, and ultimately, discovering Algolia a couple of years ago, solved so many of our issues, kept the cost low, reduced dramatically Implementation therefore GTM timelines, and freed up so much of our engineering bandwidth. They have SDKs for most common languages and platforms, and you can achieve a complete solution in just a matter of hours if not minute. Value your own/your team's engineering time. Factor that in when comparing costs. There should also be entry-level tiers you can get a proof of concept rolled out with.

Hi Erin! First of all, you'd probably want to go with a managed service. Don't spin up your own MySQL installation on your own Linux box. If you are on AWS, thet have different offerings for database services. Standard RDS vs. Aurora. Aurora would be my preferred choice given the benefits it offers, storage optimizations it comes with... etc. Such managed services easily allow you to apply new security patches and upgrades, set up backups, replication... etc. Doing this on your own would either be risky, inefficient, or you might just give up. As far as which database to chose, you'll have the choice between Postgresql, MySQL, Maria DB, SQL Server... etc. I personally would recommend MySQL (latest version available), as the official tooling for it (MySQL Workbench) is great, stable, and moreover free. Other database services exist, I'd recommend you also explore Dynamo DB.

Regardless, you'd certainly only keep high-level records, meta data in Database, and the actual files, most-likely in S3, so that you can keep all options open in terms of what you'll do with them.

Hi Aashwiin, Looking at your stack (https://stackshare.io/aashwiin82347/my-stack), it seems you are using Azure SQL Databases. I'll infer this is Microsoft SQL Server. Therefore, it certainly makes sense you stick with some of the official Microsoft Tooling to connect to it, query and administer it. You'd only be looking at MySQL Query Workbench, if you were running and connecting to a MySQL Database.

• That said, could Azure MySQL (https://docs.microsoft.com/en-us/azure/mysql/overview) be an option for you a this point? MySQL offers great performance. I have been running it at various companies (under AWS/RDS and AWS/Aurora) and have no reason to switch over to anything else.
• Decision making-wise, how much do your want your local sql/mysql client to influence/weigh in your architecture/technology decisions, though? This can be a slippery slope.
• Alternatively, other clients exist, such as "Table Plus" and allow you to connect, on Mac, to a variety of database servers, including SQL Server. It might be worth giving it a try.

Hi Vibhanshu, When it comes to serving a static website, single page application, S3 or a combination of S3/CloudFront, is a great fit. There is no server that you need to manage, and S3 is as resilient and scalable at it gets. Moreover, it's certainly the most cost-effective solution you'll be able to come up with. Is your application fully static or does it come with compute needs?

• Regardless, I would highly discourage you from running anything directly on a custom EC2 instance of your own, as this will from the get-go but also over time, come with high maintenance costs.
• Elastic Beanstalk, (not to be mistaken with EBS, which acronym stands for Elastic Block Storage), on the contrary, is a rather powerful way to manage your applications and environments. Either via the CLI or through the console, you can easily configure your environment variables, load balancers, certificates, events/thresholds causing your instances counts to scale up/down, steaming of logs...
• Elastic Beanstalk supports by default a couple of language, but these don't always allow you to run the version/dependency you need. For best decoupling from the underlying instances, you might want to look at leveraging Docker (Elastic Beanstalk has Docker-compatible AMIs), so you are in control of the stack you application runs on.