Technology is usually just a means to an end. Unless IP is what you are selling, boring is great. I’ve seen SO many teams burn SO much energy on complicated stacks just to drink kool-aid. It’s mind bogglingly frustrating, especially as a contractor. At the end of the day it’s great for me: I get brought into shit shows to clean up the mess. But deep down, I want projects to succeed and clean/sound systems architecture is how you do that. Doesn’t matter if it’s PHP, Python or Java.
It hurts to see people continue to make mistakes over and over, so I’m working on a new website and series of engineering posts to help share my approach to a lot of these problems.
Any product I start building usually begins in Rails. React is great. Vue is great. It’s not necessary, good ol’ request/response is just fine. You don’t need a service mesh. You don’t need Kafka. You add that stuff later when it’s required... if it’s required. Rails can’t be beat for startups. I wouldn’t waste any time on a single page app, it’s a completely pointless endeavor unless you have proven traction, users, revenue etc... and can afford to do it correctly.
Yes! So much this. Every startup I've worked with regretted choosing a trendy tech stack early on. Speed of development is BY FAR the most important thing and the SPA/Javascript framework de jour trend of the past few years is an antithetical to rapid iteration. As a consultant, I'll happily bill hours to untangle that mess, but it's very frustrating to see startups with lots of potential spinning their wheels with unnecessary bloat on the front end.
The only problem I see with rails is that it's hard to find devs these days (at least in Europe). Even if they could learn Rails for that project, many I've spoken to wouldn't want to take a job where Rails is required. I just witnessed a project switching from rails to React (for the frontend) because they just couldn't get enough good people willing to use Rails.
Why is HN so against people who _enjoy_ engineering? Why should I run some run-of-the-mill stack that has enourgmous legacy cruft and just not "fun".
Not every business wants to be sillicon-valley optimized money farm - some people want to do some enjoyable work.
However, the post indicates React + Redux for the front-end. Perhaps it's my bias as a back-end curmudgeon, but those strike me as _unboring_ choices in the front end, particularly if you're not targeting SPAs.
My point being: one person's "boring" could be another person's anything from "clunky and archaic" to "faddy" to "efficient and sensible." Not even Rails, built upon Ruby's idiosyncratic blood magick, is an entirely uncontroversial choice.
I agree with your overall point, however I disagree with the "just pick Rails and don't do SPA" part. For startups or any small team, the right approach is whatever boring technologies the team is comfortable with. If that is Rails, great! I personally don't know it so that would be a horrible choice for me. Likewise SPAs are comfortable and easy for me (aka boring), but a bad choice for someone else who isn't comfortable with them.
I think Phoenix LiveView is offering a very compelling value here. You are basically writing a regular server side app that will perform on par with SPA for most use cases.
I wonder what is wrong with single page apps? As I see it you can largely write the same code, you just have the additional option of modifying the page on the fly.
I would go with spring boot.
Sure rails is a faster start, but when it grows it becomes a mess.
Spring boot gives you the fastest start in JVM-land, and if your product is successful and you need things to scale, or features are getting complex, you still have the spring framework in the insides that you can manage. Boot is almost just defaults.
But spring boot wouldn't exist, if rails didn't change the landscape of web development.
I ran a small company like this quite successfully earlier in my career. If you think this is awesome what goes unmentioned is how lonely it can get. Also, any issues you have (business or technology) you bear the brunt of alone. A coworking space doesn't really help either imo, if you like working with others you will miss having coworkers. Just something I think worth mentioning if you think this is something you might want to pursue.
This seems super complex to me. I am a single dev that runs a $30k\mo software based company off of PHP+MariaDB+bootstrap+jQuery+few other plugins. Hosted on a managed HIPPA setup. The firewall+app+DB servers run me about $550\month and I have excellent support. I spend effectively 100% of my time on business logic\ui and zero time keeping up to date on infrastructure (and learning it). Which means my customers benefit from me fixing problems and adding features. Kudos to what works for you....super great... And, for me at least...it is even more "boring" and awesome.
I love these stories. I'm a one-person company too: contribsys.com.
My production server stack is Apache + some Ruby CGI scripts, to serve static files and handle billing webhooks. I spend less than an hour per week on devops maintenance.
KISS is the #1 principle when scaling a solo operation.
I thought I was reading my own blog post :) We use very similar tech stack at my current company:
- Ansible for provisioning
- Python/Django for website/api
- VueJS for frontend(where needed, some pages are simple Django templates)
- Celery for background work
- uWSGI and Nginx as servers with AWS Load balancer
- Elasticsearch for search
- Redis for caching
- Postgres with Postgis as main datastore
- Datadog for monitoring
- Cloudflare for DNS
Some differences as I am working with a team:
- We do use multiple branches and git tags for releases. Feature branches are also common as multiple devs maybe working on different features.
- We use Gitlab-CI a lot for testing and auto-deployment(ansible script can be called from our machine as well)
- Terraform for infrastructure provisioning. We have stopped provisioning any AWS service by console. Once the service is provisioned by terraform, ansible takes over.
I have tinkered with Docker, Hashicorp Packer but this setup has been dead simple to reason and scale reasonably well.
That's awesome and it is a tech stack that I try to mirror and am confident running myself as well!
It's incredible the amount of knowledge required for a single person tho when you think about it eh? It's the full frontend (which I would have more trouble with) + databases + caches + search engine + metrics + deployment + source control + sysadmin all baked in a single person who is also trying to make it a business!
Kudos for the effort and making it happen, one day I might be joining the same journey with the same stack! Just gotta figure out what actually motivates me to build a business on top of =)
as someone who has only worked on small teams, i thought this was normal. My current position is leading a small team, but we have interactions with a number of teams inside of FANG companies and it's amazing the limited amount of knowledge and access each position/person has. Most of my engineers can run circles around our partners.
I always thought every engineer should know how to deploy a server, install deps, understand caching, etc and setup an app... turns out, that is apparently not even remotely expected at most companies. I guess the bigger the company the more narrow the skillset required.
I finally created an account because your comment resonated with me. I have created 95% of my platform by myself which itself was the manifestation of several business ideas. I started out buying servers and starting a dedicated, then vps, then shared hosting farm that requires all of the frontends you mention. I took a different approach, I went all out open-source and spent time creating glue and flashy bootstrap frontends to orchestrate everything reliably.
I currently run the remains of my companies as a lab that is spread out to a few datacenters and provides a UX where anyone can request a VM, launch a container, or drop a php/java war/RoR/django/etc onto a custom app server of varying security restrictions. You can request a service/vm/container by API, by chat, or any other host of events through my half-baked event controller and change mgmt database. In a lot of cases, changes are a two-way street. You can modify e.g. a bind zone file and that will reflect upwards in a CMDB or vice-versa and watch the zone file update automagically. The original idea was to allow mixing sysadmin strengths and still maintain a reliable complex system.
So now I have a platform that spans multiple datacenters, uses infra as code as you would expect (supporting another cloud provider is simply adding glue to their apis), has loadbalancing and SSO, and it's just literally sitting on the sidelines exhausting the remaining budget until I finally get tired and liquidate it all. The motivation of building a business on it is so tiny after years of failed attempts and seeing the shared cloud model completely destroy ROI on holding hardware. I can and have built e.g. fleet tracking services. I have gobs of storage, so I run an object store for giggles. But have no clue how to generate revenue from these ideas when the market is already saturated. My last ditch idea is to create a learning ground for the public. Training on how to build apps that scale, manage systems at scale, and give a real world environment to folks who may otherwise not work at an organization with more than 100 servers. shrug . until then I chop-chop away at my dayjob :)
First, that's a great stack and very well written/presented.
One comment - he dismisses serverless as being overengineering. I think the correct POV, moreso for the single-man company, is that running a server to perform a task is the overengineered option.
One can see from the snapshot the servers are indeed severely overprovisioned and underutilized. Building an api with api-gateway + lambda is less work than running django in uwsgi behind self-managed nginx, and is guaranteed to be more cost-effective for unpredicted load.
Same logic applies to the db servers - why not hosted?
And last - the inf is a good reminder that prefixing your api routes with /v1, /v2 is always a good habit.
Good point! For people who have tons of experience with serverless, serverless is probably a better choice than running servers for some use cases.
As a small business owner, there are two types of cost that I need to consider:
Time: the time I use to do A is the time I can't use to do B. Unfortunately I haven't used serverless so far in my professional career -- in this sense, I'm not full-stack enough :) It takes time for me to learn it, understand it, operate it, and experience various outage scenarios to gain the true learnings. It's more costly for me (probably not for others) to use serverless than the things that I already understand. I'd rather spend more time on other non-engineering things nowadays -- believe it or not, I spend 1/3 of my working hours replying emails :)
Money: the money I spend on A is the money I can't spend on B. I decided not to use api-gateway + lambda & hosted db servers, primarily because of $$$. I actually did the pricing calculation a few times last year. In addition, api-gateway + lambda also require some time for me to learn, which I should use to talk to users, marketing, building new product feature, thinking (yep, thinking also uses some time budget :)...
I think the correct POV, moreso for the single-man company, is that running a server to perform a task is the overengineered option.
I was all gung-ho about serverless for a while. I wanted to release a demo for my product and thought I'd cut through all the hassles of managing my own server.
I found it bewildering. It was a whole new skillset with new benefits, but also new considerations and headaches. When push came to shove and the clock to release my demo started ticking down, I just went back to a linux server.
I use the same linux distro at home and on the server, and there are about 3 technologies I need installed. On retrospect I think I made the right decision, but happy to have my mind changed.
> Building an api with api-gateway + lambda (...) is guaranteed to be more cost-effective for unpredicted load.
Depends on the use case. I run a cron monitoring service on a similar nginx/uwsgi/django/postgres stack [1]. My service needs to handle lots of really small and simple HTTP requests, and almost every request needs to do a (small and quick) database write. I did napkin math – at the current usage levels, Lambda per-request fees alone would use up significant chunk of my current hosting budget.
Yep, learning how to run your own business is the only way to convert 10x development aptitude to a 5-10x pay increase. Otherwise you get 1x pay, 10x the expectations, upset colleagues that feel inferior in comparison, and very little promotion chance because the company needs you right where you are.
Alright. Just make a "boring" website now, it's "easy".
If it's one thing i really dislike within both the scientific and the technological sphere it's this arrogance disguised as common knowledge. Because it's not. Articles like this is nothing but bragging. The author, whoever it is, clearly has a very long time working in the field acquiring this knowledge. Be humble.
I'm a one-person company too ( geocode.xyz ). My tech stack is even more boring than that. (Nginx, MariaDB, Perl on AWS Ec2 Linux instances. I don't have an office either.
Picking your stack/architecture based on team size is something most engineers miss.
Microservices, great for companies with many teams. Not so much when it's three people scrambling to create something meaningful. Monolith all the way.
It's funny because microservices are explicitly targeted at solving problems for development with many teams, and lots of single team companies cargo cult them. Did they miss the first paragraph when they were reading up on what microservices are?
My thought exactly. I was expecting good ol'LAMP or something along these lines. I think here "boring" means "has been released for more than a couple of years".
TBH, this is more inspiring than I thought. I thought this would be some BS article about promoting your company but turns out, it was a fun and inspiring read.
My dream is to find a good idea and work solo. It is a little harder as a mobile engineer but you're right as you mention in the blog. There are technology nowadays that help me with backend/dev tools.
This looks like a great service; I just signed up for it and created my own listen later playlist. I spend 6-8h a week on my mountain bike and I use most of that time to listen to podcasts. The challenge with how I do it (using just an Apple Watch) is curating my feed. This is an excellent tool and a far better UI for curating a feed.
I also like the different and varied sources of income that you have, from the transcription service to ads to your API. Seems like you've built a great platform that you can use to experiment with different revenue models.
One additional question - your product is called Listen NOTES. Are you planning on adding note taking functionality to it at some point? One thing that I've always wanted to do was to jot down some set of notes to myself (typically during one of my bike rides). I always imagined that being some kind of voice activated thing, but I'd like that note sync'd to the spot within the podcast that I was listening to (and perhaps transcribed as well). Any thoughts about building something like this?
> Wait, how about Docker / Kubernetes / serverless? Nope. As you gain experience, you know when not to over-engineer. I actually did some early Docker work for my previous employer back in 2014, which was good for a mid-sized billion-dollar startup but may be overkill for a one-person tiny startup.
I really think the key thing here is familiarity. K8s is a bit different, but certainly in OP's position I (personally!) would be more comfortable with an image for each component. Perhaps a machine image rather than docker, if each component is going to be on its own machine as described, but something at least semi-reproducible for sure.
When I'm working on something alone, and particularly if on and off and not for several hours every day I need to be able to come back to it in a sort of self-documented state that doesn't leave me scared to touch anything lest it crumble.
A super interesting and refreshing read, especially since I am not very knowledgeable about web technology and most of the talk these days is about the latest fancy framework or database.
I am curious though, since I am using Google Cloud (App Engine in particular) for most of my company's modest backend needs: Would Google AE be able to handle all these backend requirements as well (but obviously without all the configuration and setup required)? Or asked another way: When is the point when you should move away from something easy and low-hassle such as GAE to something more advanced that requires a bit more manual configuration like setting up your own AWS servers?
Not trying to be critical, just honestly trying to learn from folks that know better than I.
[+] [-] whalesalad|6 years ago|reply
It hurts to see people continue to make mistakes over and over, so I’m working on a new website and series of engineering posts to help share my approach to a lot of these problems.
Any product I start building usually begins in Rails. React is great. Vue is great. It’s not necessary, good ol’ request/response is just fine. You don’t need a service mesh. You don’t need Kafka. You add that stuff later when it’s required... if it’s required. Rails can’t be beat for startups. I wouldn’t waste any time on a single page app, it’s a completely pointless endeavor unless you have proven traction, users, revenue etc... and can afford to do it correctly.
[+] [-] chrischattin|6 years ago|reply
[+] [-] dx034|6 years ago|reply
[+] [-] kabacha|6 years ago|reply
[+] [-] theonething|6 years ago|reply
> so I’m working on a new website and series of engineering posts to help share my approach to a lot of these problems.
Do you have a mailing list or something to get on to get updated on this?
[+] [-] phlakaton|6 years ago|reply
My point being: one person's "boring" could be another person's anything from "clunky and archaic" to "faddy" to "efficient and sensible." Not even Rails, built upon Ruby's idiosyncratic blood magick, is an entirely uncontroversial choice.
[+] [-] rpedela|6 years ago|reply
[+] [-] qaq|6 years ago|reply
[+] [-] brillout|6 years ago|reply
Node.js is missing a great ORM but other than that I don't see many things missing in Node.js anymore.
There is also Rails' admin panel but most projects don't need that.
[+] [-] NohatCoder|6 years ago|reply
[+] [-] chopete|6 years ago|reply
Its because
https://vimeo.com/76499047
[+] [-] mattbillenstein|6 years ago|reply
[+] [-] UserIsUnused|6 years ago|reply
But spring boot wouldn't exist, if rails didn't change the landscape of web development.
[+] [-] jcroll|6 years ago|reply
[+] [-] jstummbillig|6 years ago|reply
I was expecting something more along the lines of PHP + a single MySQL machine, plus all the accounting is done on a tablet made of actual stone.
This is not that.
[+] [-] ademup|6 years ago|reply
[+] [-] mperham|6 years ago|reply
My production server stack is Apache + some Ruby CGI scripts, to serve static files and handle billing webhooks. I spend less than an hour per week on devops maintenance.
KISS is the #1 principle when scaling a solo operation.
[+] [-] karambir|6 years ago|reply
- Ansible for provisioning
- Python/Django for website/api
- VueJS for frontend(where needed, some pages are simple Django templates)
- Celery for background work
- uWSGI and Nginx as servers with AWS Load balancer
- Elasticsearch for search
- Redis for caching
- Postgres with Postgis as main datastore
- Datadog for monitoring
- Cloudflare for DNS
Some differences as I am working with a team:
- We do use multiple branches and git tags for releases. Feature branches are also common as multiple devs maybe working on different features.
- We use Gitlab-CI a lot for testing and auto-deployment(ansible script can be called from our machine as well)
- Terraform for infrastructure provisioning. We have stopped provisioning any AWS service by console. Once the service is provisioned by terraform, ansible takes over.
I have tinkered with Docker, Hashicorp Packer but this setup has been dead simple to reason and scale reasonably well.
[+] [-] aprdm|6 years ago|reply
It's incredible the amount of knowledge required for a single person tho when you think about it eh? It's the full frontend (which I would have more trouble with) + databases + caches + search engine + metrics + deployment + source control + sysadmin all baked in a single person who is also trying to make it a business!
Kudos for the effort and making it happen, one day I might be joining the same journey with the same stack! Just gotta figure out what actually motivates me to build a business on top of =)
[+] [-] mtnGoat|6 years ago|reply
I always thought every engineer should know how to deploy a server, install deps, understand caching, etc and setup an app... turns out, that is apparently not even remotely expected at most companies. I guess the bigger the company the more narrow the skillset required.
[+] [-] grepfru_it|6 years ago|reply
I currently run the remains of my companies as a lab that is spread out to a few datacenters and provides a UX where anyone can request a VM, launch a container, or drop a php/java war/RoR/django/etc onto a custom app server of varying security restrictions. You can request a service/vm/container by API, by chat, or any other host of events through my half-baked event controller and change mgmt database. In a lot of cases, changes are a two-way street. You can modify e.g. a bind zone file and that will reflect upwards in a CMDB or vice-versa and watch the zone file update automagically. The original idea was to allow mixing sysadmin strengths and still maintain a reliable complex system.
So now I have a platform that spans multiple datacenters, uses infra as code as you would expect (supporting another cloud provider is simply adding glue to their apis), has loadbalancing and SSO, and it's just literally sitting on the sidelines exhausting the remaining budget until I finally get tired and liquidate it all. The motivation of building a business on it is so tiny after years of failed attempts and seeing the shared cloud model completely destroy ROI on holding hardware. I can and have built e.g. fleet tracking services. I have gobs of storage, so I run an object store for giggles. But have no clue how to generate revenue from these ideas when the market is already saturated. My last ditch idea is to create a learning ground for the public. Training on how to build apps that scale, manage systems at scale, and give a real world environment to folks who may otherwise not work at an organization with more than 100 servers. shrug . until then I chop-chop away at my dayjob :)
[+] [-] avip|6 years ago|reply
One comment - he dismisses serverless as being overengineering. I think the correct POV, moreso for the single-man company, is that running a server to perform a task is the overengineered option.
One can see from the snapshot the servers are indeed severely overprovisioned and underutilized. Building an api with api-gateway + lambda is less work than running django in uwsgi behind self-managed nginx, and is guaranteed to be more cost-effective for unpredicted load.
Same logic applies to the db servers - why not hosted?
And last - the inf is a good reminder that prefixing your api routes with /v1, /v2 is always a good habit.
[+] [-] wenbin|6 years ago|reply
As a small business owner, there are two types of cost that I need to consider:
Time: the time I use to do A is the time I can't use to do B. Unfortunately I haven't used serverless so far in my professional career -- in this sense, I'm not full-stack enough :) It takes time for me to learn it, understand it, operate it, and experience various outage scenarios to gain the true learnings. It's more costly for me (probably not for others) to use serverless than the things that I already understand. I'd rather spend more time on other non-engineering things nowadays -- believe it or not, I spend 1/3 of my working hours replying emails :)
Money: the money I spend on A is the money I can't spend on B. I decided not to use api-gateway + lambda & hosted db servers, primarily because of $$$. I actually did the pricing calculation a few times last year. In addition, api-gateway + lambda also require some time for me to learn, which I should use to talk to users, marketing, building new product feature, thinking (yep, thinking also uses some time budget :)...
[+] [-] lacampbell|6 years ago|reply
I was all gung-ho about serverless for a while. I wanted to release a demo for my product and thought I'd cut through all the hassles of managing my own server.
I found it bewildering. It was a whole new skillset with new benefits, but also new considerations and headaches. When push came to shove and the clock to release my demo started ticking down, I just went back to a linux server.
I use the same linux distro at home and on the server, and there are about 3 technologies I need installed. On retrospect I think I made the right decision, but happy to have my mind changed.
[+] [-] fovc|6 years ago|reply
As a solo entrepreneur I can say time risk is a crucial thing to be mindful of. I'll take 10h +/-1h vs 5h +/- 15h any day.
[+] [-] cuu508|6 years ago|reply
Depends on the use case. I run a cron monitoring service on a similar nginx/uwsgi/django/postgres stack [1]. My service needs to handle lots of really small and simple HTTP requests, and almost every request needs to do a (small and quick) database write. I did napkin math – at the current usage levels, Lambda per-request fees alone would use up significant chunk of my current hosting budget.
[1] https://blog.healthchecks.io/2019/08/a-look-at-healthchecks-...
[+] [-] tiborsaas|6 years ago|reply
[+] [-] john_moscow|6 years ago|reply
[+] [-] buboard|6 years ago|reply
[+] [-] baalimago|6 years ago|reply
Alright. Just make a "boring" website now, it's "easy".
If it's one thing i really dislike within both the scientific and the technological sphere it's this arrogance disguised as common knowledge. Because it's not. Articles like this is nothing but bragging. The author, whoever it is, clearly has a very long time working in the field acquiring this knowledge. Be humble.
[+] [-] eruci|6 years ago|reply
[+] [-] peterburkimsher|6 years ago|reply
[+] [-] mzkply|6 years ago|reply
[+] [-] aantix|6 years ago|reply
Microservices, great for companies with many teams. Not so much when it's three people scrambling to create something meaningful. Monolith all the way.
[+] [-] eloff|6 years ago|reply
[+] [-] goodroot|6 years ago|reply
[+] [-] rhizome31|6 years ago|reply
[+] [-] tnr23|6 years ago|reply
[+] [-] halfjoking|6 years ago|reply
Boring tech would be a million dollar business running on Wordpress.
[+] [-] huangc10|6 years ago|reply
My dream is to find a good idea and work solo. It is a little harder as a mobile engineer but you're right as you mention in the blog. There are technology nowadays that help me with backend/dev tools.
Cheers.
[+] [-] localhost|6 years ago|reply
I also like the different and varied sources of income that you have, from the transcription service to ads to your API. Seems like you've built a great platform that you can use to experiment with different revenue models.
One additional question - your product is called Listen NOTES. Are you planning on adding note taking functionality to it at some point? One thing that I've always wanted to do was to jot down some set of notes to myself (typically during one of my bike rides). I always imagined that being some kind of voice activated thing, but I'd like that note sync'd to the spot within the podcast that I was listening to (and perhaps transcribed as well). Any thoughts about building something like this?
Thanks again for building this service!
[+] [-] agustif|6 years ago|reply
[+] [-] OJFord|6 years ago|reply
I really think the key thing here is familiarity. K8s is a bit different, but certainly in OP's position I (personally!) would be more comfortable with an image for each component. Perhaps a machine image rather than docker, if each component is going to be on its own machine as described, but something at least semi-reproducible for sure.
When I'm working on something alone, and particularly if on and off and not for several hours every day I need to be able to come back to it in a sort of self-documented state that doesn't leave me scared to touch anything lest it crumble.
[+] [-] geggam|6 years ago|reply
Learning system packaging and how to rebuild src packages is much much simpler than managing a container ecosystem
Think about this... if it was so easy to manage containers why does redhat still ship its operating system in packages ?
[+] [-] sieabahlpark|6 years ago|reply
Of course it's not for everyone but outright saying it's a waste of time hasn't spent much time with the ecosystem to know how easy it's become latey.
[+] [-] rsp1984|6 years ago|reply
I am curious though, since I am using Google Cloud (App Engine in particular) for most of my company's modest backend needs: Would Google AE be able to handle all these backend requirements as well (but obviously without all the configuration and setup required)? Or asked another way: When is the point when you should move away from something easy and low-hassle such as GAE to something more advanced that requires a bit more manual configuration like setting up your own AWS servers?
Not trying to be critical, just honestly trying to learn from folks that know better than I.
[+] [-] _august|6 years ago|reply
I'm primarily a front-end dev so I keep things pretty simple on the back end side.
Stack:
[+] [-] stanislavb|6 years ago|reply