> The company I work for has tens of thousands of concurrent users, plus dozens (hundreds?) of business partners all of whom are integrating with our platform.
> We are not serving static HTML pages like StackOverflow, we have dynamic content and our customers want up-to-date analytics.
Yeah that can all still be done with a simple monolithic CRUD app on just a few servers
> what I call HN driven development: k8s, microservices, cloud
I’ll give you cloud, but my takeaways from HN in the last few years have been things like:
* Postgres is a reasonable choice for a job queue
* SQLite is a valid choice for server db at quite large scale
* k8s makes sense once you have 50+ devs
* microservices address issues of team scale, not traffic scale
> Imagine you're going to build a new SaaS app. Would you think of building it on a headless CMS?
I'm guessing this mostly makes sense for a SaaS that's mostly about serving content to users. I wonder how common that kind of SaaS is, as opposed to a SaaS where the core functionality wouldn't be served well by a CMS, and the administrative tedium that one wants to alleviate mostly has to do with account management, payment processing, enabling or disabling service based on billing status, etc.
> What we need is a cloud platform that allows people to deploy code to computers on their home network, or any cloud, or any data center... one that encourages and assists with cloud native design and aims to reduce load rather than hope you architect incorrectly and happily charge for the waste.
Sandstorm tried this, and they got very very far.
I think it was ingenious, but the sysadmin in me was very skeptical about the HA/scaling story (there was none). I guess it's fine for self-hosting for yourself&friends, but there should be an easy way forward - after all, Kubernetes commoditised clustering (I mean - once you're past setup).
Where can I follow your efforts? You mention KubeSail in your profile, but that seems developer-oriented?
> I used to work for Atlassian which made most of its money at the time I left in 2013 from on-prem software. It was low-touch, high-volume sales to people downloading and installing software on their own servers. They still sell a ton of it too.
IIRC most of their apps are Java based so the JVM ends up being their VM to normalize the installations. That would definitely simplify things and you see it even today with on-prem apps running in containers to normalize things (ex: that's apparently how NPM runs).
> If your stack is a hodge podge of web servers, shell scripts, and cron services, I think better advice would be based on how to make your application more packageable before moving to that model.
> Your goal, when launching a product, is to build a product that solves a problem for your users.
This is the main takeaway, in my opinion. I've been at small companies who were under-architected "because we can" and large companies who were over-architected because someone in the leadership chain was enamored with a particular technical choice.
In the end it's a cost curve and depends heavily on the nature of your business. I can say personally if the business is even mildly complex (not necessarily large, this could mean a web app + a mobile app + a single RDBMS) I'd sleep better having some AWS (or other cloud) alerts set up to monitor uptime/etc. Others have mentioned CI/CD, but again, heavily depends on your needs. I worked at one place that survived uploading .zip files to Elastic Beanstalk for _years_ to update our PHP website.
For some of the other data compliance/up-time/service availability stuff, I'd expect to have the revenue to cover the sort of overhead that introduces (otherwise you're just not charging enough, or the business isn't really as viable as you think).
> Sure stuff like firebase and similar works for CRUD apps but as soon as you want to do more specific stuff they usually are worthless.
Agreed again, but the fact that you have the option to use Firebase at your discretion is better than not having the option to use.
> I have never used any of these backend as a service but I would assume you would struggle a lot with all kinds of data processing that needs to happen on the server side?
It depends on the use case, and that is key. Too many engineers spend too much time arguing on a hacker news that their way is the One True Way (Trademark) - that is not always the case. Your business needs should drive your tech stack choice, and no one tool is perfect.
So if, like in your example, your use case involves a lot of data processing in the back end, then the choice is easy: favor building the custom server and associated data processing yourself, over using a BaaS or FaaS. However, if you are building a CRUD app where you have like less than 1,000 people using your app, you're time constrained, you don't have enough devs, then Baas/FaaS starts to become a more viable option.
> From a technical point of view, this SaaS processes a large amount of requests per second from anywhere in the world, and stores the data in an efficient format for real time querying.
That is the closes thing to a number of requests I could find. So this architecture, no matter how solid, is somewhere between „way to large“ and „matches perfect“.
It seems like a solid breakdown on how to deploy your services to k8s and how to properly do CD deployments. But it does never mention whether it actually makes sense at the scale he actually has.
> We are moving to Fastly. Sucks because we built so much around Cloudflare.
Are there concerns about getting locked into Fastly’s cloud services instead of Cloudflare’s? Will you use some level of abstraction to make the deployment more portable, or that’s another bridge to cross if needed?
> I never really understood the hatred that people on HN have for microservices.
If you're an early stage company and just trying to ship something with a small team, the overhead of microservices (testing, deployment, monitoring, platform infra such as k8s, etc) can be pretty obnoxious (like an order of magnitude more time than the work to actually deliver business value). And microservices give you enough rope for one overly clever person to hang the whole team, so there are definitely some traumatized developers out there.
If you are doing something simple enough, throw it in a single docker container and spend your time focused on building something useful.
> Comparatively speaking even compare them to the same CRUD app and DB, most are using 5 to 10x more servers with 1/2 to 1/5 of the traffic.
No doubt, but how large are those other CRUD app organizations? Do they have a staff that is 20x the size all trying to coordinate deployments on the same handful of servers? What are their opportunity costs? Is trimming down server expenses really their most valuable opportunity? No doubt that SO has a great Ops capability, but it's not the only variable at play.
> Does this stack really put everything under the sun to shame?
Yes. I'm a .NET guy by trade and I've poked around Elixir/Phoenix a bit. I wish this stack (and its concepts) would gain some popularity in the enterprise so we could get rid of microservices and SPAs entirely. 99% of companies don't need Microservices, they solve problems they don't have at costs they shouldn't have to pay (velocity, complexity, etc.) SPAs could go away for most LOB apps with Phoenix Live, Blazor (.NET), or even just classic server-side web apps + Htmx.
> I've finished constructing a small repository which runs the following in order to setup a cluster: Bazel, Terraform, Packer, Ansible (which'll run `kubeadm init`), Docker, Kubernetes, Openssl, Jsonnet.
It's pretty sad that in 2019, to setup a web app that can properly scale you need to understand and use so many technologies. Developing a scalable website in 2013 was a lot easier than in 2019. Back then PaaS was all the rage (Heroku, Google App Engine, Amazon Elastic Beanstalk). Since then, things have gotten much harder.
I suspect that this development has less to do with technical challenges and more to do with revenue. Cloud providers now provide all of these services, and they make little money getting small folks up and running with something that "just works". The real money is going after enterprise clients that need to tweak every detail and have the resources to devote to all of these technologies.
There have been so many platforms and libraries that have come out over the past 10 years, the industry is more than ready for a period of consolidation.
>It's pretty sad that in 2019, to setup a web app that can properly scale you need to understand and use so many technologies. Developing a scalable website in 2013 was a lot easier than in 2019. Back then PaaS was all the rage (Heroku, Google App Engine, Amazon Elastic Beanstalk). Since then, things have gotten much harder.
Is there anything stopping you from using these? Because they're well maintained and even better than before. In fact, many companies and individuals are still using them. And if you have different needs, it's good that there are more flexible alternatives, no?
> Don’t get stuck with building a platform stack with Platform as a Service (PaaS) offerings from Heroku, CloudFoundry and OpenShift – we’ll give you out-of-the-box features that offer a much easier and richer user experience.
That's a useless pitch, it tells me nothing about the product, which simply generates an API for you. (I had to go to the website to figure that out -- http://www.kinvey.com/) I can't imagine this as a one-size-fits-all solution, except for the simplest of CRUD apps.
> Don't migrate an application from the datacenter to the cloud
Reading the actual text of this one I get a different impression, but I'm still not sure I agree with this one. Applications can be radically different from each other in terms of how they are run.
At one company, we ran a simple application as SaaS for our customers or gave them packages to run on-prem. We'd stack something like seven SaaS customers on a single set of hardware (front-ends and DB servers). The cloud offering was a no-brainer, you can just migrate customers one by one to AWS or whatever, or spin up a new customer on AWS instead of in our colocation center.
Applications have a very wide range of operational complexity. Some applications are total beasts--you ask a new engineer to set up a test environment as part of on-boarding and it takes them a week. Some applications are very svelte, like a single JAR file + PostgreSQL database. The operational complexity (complexity of running the software) doesn't always correspond to the complexity of the code itself or its featureset.
> We need more frameworks that scale from a single box to many boxes, without starting over from scratch.
I'm not sure I really understand what you're saying here. I suppose most applications are some kind of CRUD app these days, not all sure, but an awful lot. If we take that as an example, how is it difficult to go from one box to multiple?
It's not something you get for free, you need to put in time to provision any new infra (be it baremetal or some kind of cloud instance) but the act of scaling out is pretty straight forward.
Perhaps you're talking about stateful applications?
I would love to hear what tech stack (or stacks) the HN community thinks currently allows a small team to move fastest for this type of product.
reply