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.
The current project I work on is angular1 based witch is outdated and it also sucks if the dev was just learning it at the time, the backend is done with a PHP framework that is today outdated/deprecated, this is not an old project(probably started when angular was the hot new thing)
I am sure your react project in 5 years if you will try to build it from scratch you will find issues with the npm dependencies, lots of deprecation warnings in your modules in react. I am all for the best tool for the job , use SPAs where it makes sense,
For example, many vanilla PHP applications written 10 years ago will still run just fine today, whereas upgrading from one version of Laravel to the next version can be a major trauma.
it happens in JS land too, find some js package made by a newb and run a linter on it, I see issues on code that is written by coders with a few years of experience where they do not use properly the array functions, do not use correctly the lamda, they copy paste same code in 3 or more places.
Do you think that all js,Ruby or Pthon dev would properly use SQL without an ORM? I dpn;t think so, I found recently bugs in a JS codebase where file upload would fail if the file had non US characters in it's name because some parameter was not url encoded, so all developers make mistakes and ORMs were not popular at that time to prevent this kind of mistakes for SQL.
pick your poison i guess.
Also it sucks when you search for help and you need to double check if the solution is for yii1 not 2, or angular1 not the others etc.
that means when selecting a framework, don't pick the newest, but look for something that promises stability, and then stick with it. i picked aurelia to once angular 1 was no longer usable. and although i mainly chose it for other reasons, it looks like it will be a stable choice.
It is what it is, I will have to learn and maintain others code like I always done but it would be better if we had some stability as I mentioned, some standard web framework built in JS and browsers that most developers would use and the devs that want new and shiny could ignore that and use whatever.
For web when I inherit an older project I need to spend a lot of time in finding the correct version of things, like for an older react project it was using an official jsx transpiler but today that package is deprecated you can't just npm install it, so I would have been forced to upgrade the entire build system to use the new thing , but at that moment I had to fix a small thing so I found a hack for the issue and postpone the fixing of that issue.
What I think Web needs is some standard framework, or a framework core maybe jsx or other template thing but something standard to be used in mst projects and for side projects we can toy with the shiny new frameworks and languages.
I want a DataGrid with sortable and re sizable columns, i need to search the web, find something that is compatible and also make sure the license is compatible
I want a basic Dropdown widget that can do basic things like ex have a flag+country name or have a list of fonts where each font is using it's family to be rendered. Also the scrollbars can't be themed for when elements overflow in all browsers so you are forced to find something that reimplements the scrollbars.
When I give example of Qt,Net or Java I include the full SDK , if you did not worked with this kind of SDKs maybe you worked with Android one, basically you have the language STL plus anything you need from file I/O, Networking, Widgets, to the serial ports,screen, and a lot of things, you don't have to package install a new thing for each feature.
All the stuff you mention can be solved with simple libraries, maybe you could push for a library that solves such problems to be widely adopted. But frameworks always bring a new set of problems of their own, which is why no one is ever going to agree on the subject of those.
There is no need that browsers select things that are agreed but 100% of people, it needs to satisfy the needs of a large majority that need to create boring and stabe websited or applications.
I am wondering if in a few years you can pull a project from Github, run npm, gulp (or whatever the REAMDE says) and it will just work.
I feel way more productive today than in the old jQuery, knockout messes
I've spent a lot of time building CRUD APIs and GraphQL interfaces, and this is the simplest solution that has saved me so much development time. JSON RPC gets so much hate, but it's made my life so much simpler.
The main focus is to:
- easily share React components that use Redux state and actions between projects
- rapidly develop new server-side services and immediately use them in React components (by removing code duplication
when it comes to creating action creators and action types)
- have type safety
- provide basic server-side and client-side components for basic user actions such as login, user profile, etc
- make it easy to write tests
And at some point in the future, I hope to make it generic enough so the libraries mentioned above can be swapped for other libraries, but that might be too much work :)
PS - I need to build an api for an app with a React front-end. My choice of language is Python (because I'm super familiar and because of the great ORMs Python has).
It’s my go to tool when I need to get stuff done. Combined with react and typescript, developing full stack is really smooth.
i like next.js now but for simplicity's sake i think parrent is right.
But spring boot wouldn't exist, if rails didn't change the landscape of web development.
But again, that's just my experience, it may differ for other companies and/or regions.
If you need a contractor to help with a Rails project drop me a line (my email's in my profile). Been working with Rails since 2.x days. Not in Europe tho I'm GMT-4.
Engineers, as practitioners of engineering, are professionals who invent, design, analyze, build, and test machines, systems, structures and materials TO FULFILL OBJECTIVES AND REQUIREMENTS WHILE CONSIDERING THE LIMITATIONS IMPOSED BY PRACTICALITY, REGULATION, SAFETY, AND COST.
OP's approach is mighty fine for his own endeavors, but if I had such a worker hired, there would be a serious talk about priorities. If no agreement is found even 100x engineer would be let go.
edit: to be clear, I'm not claiming to be a 'real' engineer. I love writing whimsical, complicated stuff if it makes things easier for users, and make sure I'm writing maintainable code my colleagues are comfortable with with code reviews and removing as many flourishes as possible.
I also love to experiment with new interesting stuff. But that's not engineering, it's learning.
Remember: You will not retain talent if you want them to act like code monkeys.
Your own project on your own time? Go for it. Clients should get the best fit, most reliable option, not the flavour of the moment.
(That all said, RoR is not a great choice these days as it is a niche skill)
Most of these opinions are not grounded and you can not leverage the related tools to improve the work process.
How surprising is it that, given how few variables we are left with, these variables are heavily over-engineered?
Those restrictions you describe are classic hallmarks of a toxic workplace IMHO, and somewhere I would leave as soon as I had the chance. I guess I'm lucky to have that choice.
It can be difficult to recruit for now.
(Also no, I'm not in web development, I have just observed this)
And it s debateable if learning other people’s apis is fun
> 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?
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.
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.
Node is a language that you could compare to Ruby.
You can ostensibly do the exact same thing with Node that you could do with Ruby on Rails... but you’d be reinventing the wheel all over the place and duct taping lots of different modules together that all utilize different design patterns.
If you’re good at designing systems, you can do it just fine, albeit slower than I could with Rails. But it’s possible. I have nothing against Node but there’s a time and a place for all tools. Getting an MVP up is not one of them, imho.
To make up for the missing social interaction I play football with friends, do some consultancy jobs on the side and I help where I can with my son’s football club.
This really is my dream job and I enjoy it thoroughly. I have no problems staying motivated and every day I have loads of inspiration.
The moment I lose motivation will be a sign for me to sell everything and start something new. I ran an online marketing company before this and that was really exhausting for an introvert like me. Selling that company was the best decision I ever made, apart from marrying my wife.
Did you quit work to start this, or did you manage to work around your day job?
I only learn when I have a project in mind that I want to do. No matter if it’s work on or around my house, creating an app or designing something like a logo or interior. Then I just start. Walk into a wall. Stop. Look for learning material or inspiration. Start over.
Reiterate. Learn more. Reiterate.
I’m not easily frustrated by failure, starting over or general lack of progress. If I have an interesting goal I just keep going. It might not be the most efficient way, but it’s how I learn best.
There is no magic bullet. It's a combination of inspiration, motivation and perseverance. Example: I spent 1 year learning to built an app in Swift (together with a friend, one evening every two weeks), then we decided to ditch most of what we learned and start over in Flutter, knowing that it would take us another year and I just don't care. I'll get there eventually.
I get that it’s not for everyone but I grew up on a farm so I kind of got used to the quietness early on I guess.
The hardest part of building this business is to keep motivated for a relatively long period of time. I'm still early in this startup journey. This is only the 2nd year of me working full-time on Listen Notes.
I think it would be helpful to surround yourself with like-minded people (online or offline) -- we are social animals. Indie Hackers is pretty good: https://www.indiehackers.com/
I live in San Francisco and I used to work for companies, so at least I can often hang out with some friends/former coworkers who are doing startups or working in tiny startups.
In my coworker space, people from different companies rarely talk to each other...
What you gain is the flexibility to control e.g. which extensions you want to run, and exactly how you want to set it up. How important that is really depends on what you want to do.
You managed to pull me away from my previous preference, player.fm. Good job!
We just made a Twitter recently, but it has all the links: https://twitter.com/ih_worldwide
Dedicate a given day of the month or week for all your meetings so scheduling is simpler.
Chase invoices on the same date every month, chase all invoices that are overdue by some threshold you have set. Just follow the rule, and chase using a template. Perhaps even code the first few chases into an automated system.
Try to avoid customized proposals, use templates for many things. I agree this one is hard.
Managing employees, you have to consider each employee is a force multiplier. The idea here is to invest a day to get a week or similar.
Overall, you need to just invest a limited time into each decision. After that time, go with what feels best even if it isn't perfect and move on. I find the same thing hard myself.
Especially when you think "this all works great, but would still work equally great with another human or two here."
I'll see if I can clean it up and finish it though; if you have any particular questions you'd like to see included (selfish: so I can feel like it's less braggy and more interesting), I'd love to hear them. Contact info is on profile if you don't want to derail this thread. :)
It's so hard sometimes. No one to really bounce ideas off of, every little thing you have to do yourself. Staying inspired to work is sometimes difficult, because you are literally doing everything yourself it just gets so overwhelming.
Sure, you can do it with friends etc. But at some point you just become menace asking them to think about your stuff so much.
One man show / sole proprietorship is great, but its bad for family life. It's 24x7. Atleast thats how I saw my dad, dining room was the company meeting room and we all are unpaid company "helps",assisting our Dad support the family. This is the main thing that holds me back from being an entrepreneur (sole proprietorship 2.0).
at another space i find people are more social. they organize events, coding workshops, even cooking classes, occasionally they cook meals. there is a fully stocked kitchen that everyone can use whenever they like. just pay for materials used. people often go out for meals together. etc...
when you are working, people will leave you alone, but if you know who else is there and what they do, you can talk to them and help each other. it helps that many are freelancers and not secretive startups hustling for investment money.
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.
But as I said, it depends on your history and what you work quickly with.
In the article the author says they chose Ansible because docker felt too heavyweight and unnecessary. It’s true that docker has a lot of stuff you don’t need in there, but trust me when I say Ansible is no picnic. In fact I find it easier to take what I need with Docker and Kubernetes and get running way quicker than I would ‘naked’ Ubuntu machines that I need to semi-manual previsioning with shell scripts or Ruby scripts. I got up and running with Kubernetes on DigitalOcean in less than a day, and Dockerfiles using familiar technologies I’ve used before take less than an hour to iron out.
You’ll get people who say that Docker is overkill and unnecessary and far too complicated for a solo project, but then you’ll get others who believe it’s a small file with 20 lines of declarations, sat alongside a 30 line yaml file that can provision all of your infrastructure instantly across any cloud provider you choose.
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.
For the very few people who don't know mike or sidekiq, read this: https://www.indiehackers.com/interview/how-charging-money-fo...
Didn't ruby remove its CGI libraries from their standard library somewhat recently. I believe there were mostly helper libs, but I am curious how that works.
You don't need libraries. If you have reasonably low traffic CGI can get you really far.
And even after that, I would expect that CGI augmented with some careful caching (read: all static content and some dynamic content with sensible expiration policies) will get you even farther without having to dramatically change anything.
I've always wondered about how easy it would be to setup a SAAS that adheres to HIPPA.
That said.....had I not done "this", then I probably would have done something more lucrative and "easy". I see non-PII opportunities everywhere, and (mostly) only hang around because what I do now pays the bills.
All the things they mentioned:
Ubuntu, PostgreSQL, Elasticsearch cluster, Redis, RabbitMQ, Django / Python3, uWSGI, Nginx, Celery, Celery Beat, Supervisord, React + Redux + Webpack + ES, Amazon S3, Cloudfront, react media player, Ansible, Datadog, PagerDuty, Rollbar, Slack, PyCharm, MacBook Pro, Vagrant + VirtualBox, GitHub
WeWork, iTerm2, tmux, Notion, G Suite, MailChimp, Amazon SES, Gusto, Upwork, Google Ads Manager, Carbon Ads, BuySellAds, Cloudflare, Zapier, Trello, Medium, GoDaddy, Namecheap, Stripe, Google text-to-speech API, Stripe Atlas, Clerky, Quickbooks, 1password, Brex, Bonvoy Amex card, Capital One Spark
PostgreSQL, Elasticsearch cluster, Redis, RabbitMQ, Django / Python3, uWSGI, Nginx, Celery, Celery Beat, Supervisord
On the other hand, I disagree with his points about docker being overly complex. Docker images are simple. Kubernetes, once you get the hang of it, is great on GKE and gives you automatic SSL via Google or let’s encrypt, and load balancing and auto-scaling just works. It’s probably more expensive than managing your own servers, at this level, but maybe not since you could pack more services into fewer compute instances.
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 =)
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.
A 3 person engineering team doesn't want to hire a specialist DB admin who knows Postgres back to front but can't code. A company of 1000+ engineers might, because they might have problems that require that expertise.
But any engineer working in a company of 1000+ engineers is also subject to friction resulting from resource allocation inefficiencies, communication overhead, regulatory compliance, etc: the reduced output from those factors has little to do with the specialist engineers doing worse work, and more to do with them working at the size of company that can afford to hire specialists.
(You could make the case that buck passing is an example of resource allocation inefficiencies, as it is often accidentally or purposely enabled by company management, but nonetheless, that's not a generalist vs specialist tradeoff.)
The slow progress was dictated by the extra communication to coordinate the specialists, but at the end of the day it ends up being worth it.
(All of this of course assumes you work in an org with lots of really good specialists).
iteration is slower at bigger companies but some of those teams are inventing wheels as they go. which requires slower movement than general web/mobile dev.
I am a generalist full stack developer who has built a SaaS business very similar to the way OP has. No team of me’s could’ve produced, say, TensorFlow.
Great teams and companies have generalists and specialists.
I must also point out that what FANG employees do get in abundance is the ability to learn from highly scalable systems that others build, cutting edge tech others work on, experiment on company's dime, pursue an eng/mgmt tract more in line with their personal interests, and job stability.
It also affords them an opportunity to be part of a team that one day builds a groundbreaking tech and pushes the envelope forward not just for the company but the entire industry.
In bigger companies traditionally they had a person / department more specialized per part of the stack, I think is a lot about the "devops" culture.
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 :)
- 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.
The real reason to switch would be performance. The interpreted nature of Python that makes things like Django and PyUnit possible also makes it kinda slow. Some places choose to parcel out a few key services in a faster language (C, Rust, Go) and use bindings to call out as needed.
A lot of people get caught up on "x is slow, y is fast" and try to over-architect too early on, then end up focusing on the wrong parts of their product, and sooner or later the project falls apart.
Sure I prefer static languages nowadays since I work in a much bigger company, however I think the benefits of static languages is overhyped.
- We use standard tools like flake8, isort, black for code linting.
- We are not following TDD, but we do write tests for all features. Pytest helps here
- Proper code reviews. I cannot stress this enough. As a Tech-Lead I have pushed for code reviews even when working on (supposedly) tight deadlines.
- We are also exploring to use type hints introduced in Python3.7.
PS Shout-out to Poetry(https://poetry.eustace.io/) to make our dependency management easier than ever. Updating third party libs is a lot easier now.
There are four popular typecheckers that I'm aware of (mypy , pyre , pyright , pytype ), which is a little confusing, but any of the four will catch a lot of type issues that typical statically typed language compilers would catch. It's not as robust as true static typing - there are sometimes false positives and false negatives - but I find it helpful.
> ... and it becomes not so bad to work with
How did you manage to put these two statements in a single sentence implying positivity :)
Why do people choose to explicitly write unit tests over and over again for basic things which could be caught by a compiler?
People are losing so much productivity (both short and long term) and being deceived into not having the type system "stand on their way" while they're typing out the initial prototype.
This always bites back when you start first significant refactoring.
I will never understand the appeal of the dynamically typed language. Modern, statically typed languages with strong type systems, provide so much more productivity, reliability and confidence in the codebase that it is really irresponsible to ignore them nowadays.
If you create a course on udemy/YouTube on how to setup a production full stack, there are many basic setup videos or tutorials, but none on production full stack with load balancing, replication, caching, etc
Also, I am a long time user of wakatime. Awesome product :)
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.
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 :)...
Thank you for this excellent write-up. Monetizing APIs is always a great topic; did you consider or will you consider using a 3rd party API management service such as RapidAPI or Apigee to keep track and charge for API usage?
The api was launched in Dec 2017 right here on HN: https://news.ycombinator.com/item?id=15825900
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.
For someone starting out you don't need to worry about learning Linux and how to configure Apache to serve SSL certificates in the right way, but that is important to know, unless you are happy to always rely on (and pay for) someone else to do that.
To me serverless is similar to Heroku, it's great for starting out but as you start to grow it's going to quickly become a lot cheaper to maintain you own systems. Except with serverless it's not so easy to self-host because you end up relying on all the tooling the vendor provides.
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.
Also, people seem to be dismissing the value of a rock-solid local end-to-end dev stack which with the latest iteration of technology I feel has become very complicated and expensive. The OP can run the same Ansible for his dev stack as well as his prod and his dev stack doesn't turn into an AWS bill. Most of the AWS managed tech & services is only reliably testable on AWS at a functional/integration level, which is a cost that a company this small shouldn't have to absorb.
Depends on the use case. I run a cron monitoring service on a similar nginx/uwsgi/django/postgres stack . 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.
Of course, the overarching rule is always "if it works, don't touch it".
Nontrivial cost reduction would be switching to a different host instead of aws.
As me how I know. When I was a solo dev doing my own thing, I'd spend way too much time working on things that really wouldn't affect the business but were "good engineering things" to do. If I spent more time working on things that would grow the business instead of wasting weeks writing fancy deployment scripts, maybe I'd still be doing my own thing now!
Timeframe has to be considered. If it only takes a week, I'd strongly suggest biting the bullet. A week's budget can be quickly spent troubleshooting issues, scaling servers up and down, installing software updates, hardening systems and whatnot.
It will most likely be much cheaper to run too. Which, in a single-man operation, may be worthwhile.
Also some workloads are really bad for lambda, because you can (total napkin math) run 4 cores at 100% load for 24h a day to do your processing, all at the cost of "1 instance".
It's a niche, just like all solutions that aren't a single Unix process on a single Unix box. Even CGI scripts are a niche. You pick the niche that you know.
Since the author is reading/commenting here, and there was a large amount of space in the original article outlining tools/services he uses, can I humbly suggest they use a tool like "Grammarly" or similar to help with the word-choice(s)?
Some distracting use of plurals for terms - e.g. "traffics", "stuffs", etc - may have been avoided and other spelling and grammar aspects could have helped make this easier to read. That all being said - the 'essence' of the article is to be commended.
The only issue I've found about using serverless is the database. In most cases (Firebase, Fauna, Cosmos, DynamoDB) you have to couple your stack to the DBaaS provider which is not a great idea. AWS recently announced Amazon Aurora PostgreSQL Serverless but while it allows you to use regular Postgres tools/queries you are again tied to AWS.
If you discount building an AWS-specific deployment process that includes "pip install" from an AWS linux machine image, zipping the project, and putting it in S3.
You'd also see that 7 of his 8 worker boxes are almost at 100%.
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.