51–60 of 196 posts
What's the year on this? anybody know? Normally I check the Internet Archive, but https://web.archive.org/web/*/https://danluu.com/simple-arch... .
Earlier quoted context omitted.
I'd never worked with micro-services before this latest freelance project. I start working with this platform that is basically "note taking but with a bit of AI/ML". So okay, a bit of complexity with the ML stuff, but otherwise a standard CRUD app. The application itself is a total of 3 pages, encompassing maybe 20 endpoints at the most, with about 100 daily active users. For the backend, some genius decided to buil…
_74_ services on a k8 stack for 3 pages and 100 active daily users????? This has to be a crime.
For example, in order to sign up a user...the client hits the /signup endpoint, which first lands on the server-gateway service. Then that is passed along to an account-service which creates the user. Then the accounts-service hits a NATS messaging service twice - one message to send a verification email, and another to create a subscription. The messaging service passes the first message along to the verification-service, which sends out a sendgrid email. Then the second message gets passed along to a subscription-service-worker. The subscription-service-worker adds a job to a queue, which when it gets processed, hits the actual subscription-service, which sends along a request to Stripe to create the customer record and trial subscription.
6 services in order to sign up a user, in what could have been done with about 100-300 lines of Node.
Earlier quoted context omitted.
Man, kubernetes is so much easier than the smattering of crap that you have to jungle together before it. Puppet and co? No thanks. Terraform? It's fine, but only a part of a CI/CD picture. If you think the alternatives are better, I really have to wonder how much of the trenches crap that people in your org deal with regularly that you're insulated from. That, or you're a release-quarterly kinda company?
We're using Nomad + Consul + a custom little cli and I would never go back to K8s from this. Not a yaml document in sight.
Just boils down to not optimising until you need to. Start with a 3 tier web app (unless your requirements lead you to another solution), then start with read replicas, load balancing, sharding, redis/RabbitMQ etc
Realistically almost every web app can start as a one-tier web app that uses SQLite as a data store and serves mostly HTML.
In almost all performance areas -- gaming, PCs, autos, etc -- there are usually whole publications dedicated to performing benchmarks and publishing those results.
Are there any publications or sites which implement a few basic applications against various new-this-season "full stacks" or whatnot, and document performance numbers and limit-thresholds on different hardware?
Likewise, there must be stress-test frameworks out there. Are there stress-test and scalability-test third-party services?
Even for his architecture, it sounds like they have an API service, a queue and some worker processes. And they already have kubernetes which means they must be wrapping all of that in docker. It seems like a no-brainer to me to at least separate out the code for the API service from the workers so that they can scale independently. And depending on the kind of work the workers are doing you might separate those out into a few separate code bases. Or not, I've had success on multiple projects where all jobs are handled by a set of workers that have a massive `switch` statement on a `jobType` field.
I think there is some middle ground between micro-services and monoliths where the vast majority of us live. And in our minds we're creating these straw-man arguments against architectures that rarely exist. Like a literal single app running on a single machine vs. a hundred independent micro-services stitched together with ad-hoc protocols. Micro-services vs. monoliths is actually a gradient where we rarely exist at either ludicrous extreme.
What's the year on this? anybody know? Normally I check the Internet Archive, but https://web.archive.org/web/*/https://danluu.com/simple-arch... .
Earlier quoted context omitted.
When you type something into IRC that message shows up in the log and every online users client pretty reliably. Furthermore the high degree of diversity among clients provides a pretty extreme amount of client side functionality that Slack completely lacks (scripting is a huge one.)
The versatility of clients is indeed a huge benefit of IRC. I used to use IRC at work and always had my Weechat window split with a small pane up top showing either my highlights or a channel I needed to monitor at the time. With Slack, you can’t do that, which means you have to repeatedly click between channels if you need to pay attention to multiple at a time.
https://slack.com/intl/en-gb/help/articles/4403608802963-Ope...
What country could that be? That sounds challenging.
There are some web apps still in production that I wrote almost a decade ago in Node+Express in the simplest, dumbest style imaginable. The only dependencies are Express and some third-party API connectors. The database is an append-only file of JSON objects separated by newlines. When the app restarts, it reads the file and rebuilds its memory image. All data is in RAM. I figured these toys would be replaced pretty…
> database is an append-only file of JSON objects separated by newlines. When the app restarts, it reads the file and rebuilds its memory image. All data is in RAM Apps like this tend to perform like an absolute whippet too (or if they dont, getting them to perform well is often a 5 line change). It's really freeing to be able to write scans and filters with simple loops that still return results faster than a networ…
Absolutely. The challenge is having enough faith that it will take long enough to catch up to you.
Statistically speaking, it won't catch up to you and if it does, it will take so long you should have seen it coming from miles away and had time to prepare.
In my systems that use an in-memory/append-only technique, I try to keep only the pointers and basic indexes in memory. With modern PCIe flash storage, there is no good justification for keeping big fat blobs around in memory anymore.
Earlier quoted context omitted.
When you type something into IRC that message shows up in the log and every online users client pretty reliably. Furthermore the high degree of diversity among clients provides a pretty extreme amount of client side functionality that Slack completely lacks (scripting is a huge one.)
I love irc, but is is just silly. Slack has much better history because you don't need to have been online when messages are sent to log them. Slack is absolutely more reliable in this regard. IRC is easy to script because the protocol is so simple. But you leave so much on the table for that cost. Obviously if your use case is text only that you don't care about being persistent and you lean heavily on scripting to…
Logging is just different between the two.
For IRC, logging is outside the scope of the IRC protocol. Anyone can log anything anytime anywhere with whatever policies and procedures they want. This usually leads to each channel/project having some "official" log of the channel somewhere, using whatever they feel is good for them.
Slack on the other hand centralizes the logs, which removes lots of control into the administrators/slack developers.
So Slack's logs are likely easier to find, but that doesn't necessarily make them easier to use.
Persistency is also just different, IRC makes it your problem, but it's a solved problem if you care about it. irccloud.com and sr.ht both offer persistence in different ways as two differing examples to the problem.
Slack of course centralizes the problem and removes some control.
I personally think Slack and approaches like it (I prefer MatterMost) are great for internal things where administrators need central control of stuff for various reasons. For public things, I think Slack is a bad solution, and something like IRC or Matrix is a better solution to the problem of public chat.