More power to him! I find it hard to get large blocks of quiet time now having three kids, but that's life :-) My dad was a lot like him, though, was coding or hacking around on ham radios most of the day well into his 60s.
- it can use multiple backends, including redis and a db
Now I tend to use simpler things when the project allows it, like huey and rq. Most of the time, you don't need something super powerful for your tasks.
A password manager that doesn't have an open-source client cannot be truely checked. Therefore it cannot be trusted to encrypt them before being sent nor to not contain a backdoor.
Apple was part of the PRISM program, we know they gave access to our data for mass spying.
I'm sure leaving a fertile land 100 000 years ago, crossing the desert on foot, having most people die in the process, not knowing if they was an end to that sand, felt the same.
Why would you do that?
Two centuries in the future, the benefit of going to mars will be obvious, because we will have progressed and gain things we don't know about now.
That's how humanity works. We try crazy stuff. And a lot of it is stupid, expensive and dangerous. Plus the result is disappointing.
But eventually something pays of big time.
And everybody says of course we should have done it retrospectively.
It's like people asking why we are still making purely theoretical math research. Surely it's no use, and it's expensive.
I have no doubt many people opposed to the moon landing as well on those grounds.
I expect fully the comments to answer "but this time it's not the same because...". But it's never the same.
It's always a different situation. That's the point.
Moving to Mars is the opposite: it is crossing the desert to go move into a frozen hellscape of radioactive desert.
> I'm sure leaving a fertile land 100 000 years ago, crossing the desert on foot
Actually, this kind of thing basically never happened, for some values of never.
Humans didn't leave Africa by crossing the Sahara desert. When we left Africa, the Sahara wasn't a desert.
Similarly, Aboriginal Australians didn't swim or canoe to the mainland, they walked there at a time when sea levels were lower and there was a land bridge to PNG.
Until very recently, nobody did crazy long crossings over uninhabitable lands or waters. Expansion happened incrementally, over habitable areas to other habitable areas.
> But eventually something pays of big time.
There is no reason to think that there is anything of value on Mars. No oil, no arable land, no liquid water, no unique unobtanium like in the movies. Just the same eighty or so elements, in roughly the same distribution. Just colder, drier, and impossibly far from everything you care about.
Sometimes being outside easy nuclear strike capabilities of the superpowers is a good on its own. Plus lot less annoying environmentalists and I imagine plentiful fissile material.
If literally every nuclear bomb ever made was detonated in a world war, the fallout from that would be a significantly smaller problem than the steady-state radiation is on Mars right now.
The fallout will eventually decay, but Mars will stay an irradiated hellscape forever.
With a couple fairly simple genetic modifications humans could thrive in place with high background radiation, in a place where nobody can throw nukes at you for doing simple genetic modifications.
People didn't know there was a fertile land of the other side. Just like we don't know if there is a good thing that will come out of mars. We just know the constraints.
It's not about what you know is there. It's the potential.
There is no point for Usain Bolt to run that fast. There is not point in building the tallest tower in the world once again.
Meanwhile, the mars goal already managed to bring us spaceships that land and divide the cost of putting satellites in orbit by 10.
No other path lead to it because there was nothing to motivate it enough.
This comment is really poorly reasoned imo. To continue your metaphor, ancient peoples did not sail across the Pacific *, they sailed to the next nearest island and started colonies there (if viable). You could apply your logic to argue for colonising Uranus, or even the Sun.
> Two centuries in the future, the benefit of going to mars will be obvious
IF the colonisation of Mars is successful (however you define that), the benefits of it MIGHT be obvious. Those are 2 huge conditionals; it may not be possible to colonise Mars, and if it is possible, we may still not be seeing any benefits in 200 years time.
*Of course, some did, but very much by exception. And it rarely ended well for these people, or their tribes, or humanity at large.
Managed services still require engineering efforts. I have never seen a transition to a cloud service that actually didn't end up requiring a new hire.
This is the biggest nasty secret about cloud (and SaaS for things you don't build in-house).
When my last company transitioned to cloud, all of the on-prem folks had to additionally take on that responsibility. We then had to hire a bunch of new folks to ease the transition and manage the cloud pieces. And then there are new teams spun up for permissions and security. Your headcount requirements are not going to go down because of cloud.
As for those that like to call DIY systems "weirdware": homegrown systems are expensive to engineer, but cheap to run. We 10x'd our cost going to 3rd party visibility and feature flagging versus the thinly staffed [1] homegrown systems. And those 3rd party systems also required a ton of engineering to support, the migrations weren't clean, and they missed a lot of key features that we had to upstream to the third parties!
When SignalFx got bought out by Splunk, I've never seen an annual plan get re-wired so hastily. Top priority was moving to a new vendor, and that impacted every single team in the company.
The only real tangible benefit to cloud that I've seen is that a team can instantly provision hardware, database, etc. resources without much planning. That's it. And is that worth it? (I don't really think so.)
[1] Once built, half an engineering headcount per quarter to accommodate new features. Oncall rotation for one team that owned the systems. Our stuff was high resiliency and barely paged at all. No SEV1 or worse outages ever.
I love the term "weirdware": I've seen systems like that built (and used!) first-hand multiple times in my career.
They can sometimes be very odd force multipliers in unexpected ways.
My favorite example is a home-rolled payroll applications specifically for sales people from over a decade ago. When I first arrived at the org I thought they were absolutely insane to have created such a thing. But its killer feature was that it allowed our org to pay out commissions rapidly (same day) and also allowed negotiating on a per-account residual commission basis as well as giving management the option to buy-out residuals. Off-the-shelf solutions at that time kinda-sorta did this but required either massive upfront $$$ and a ton of integration work. A plucky startup couldn't afford it. This was built, tested, and rolled-out in 45 days by 2 engineers and basically allowed them to poach top sales people because they knew they could get paid faster and had more flexibility on residuals.
That's the tradeoff everyone makes when they say something isn't in their "core competency" - they give up any real competitive advantage that area of expertise could bring them. That often makes total sense like with accounting or HR, but most companies take it way too far in engineering and internal support software.
Engineers make the same mistake all the time too: we love to say that "premature optimization is the root of all evil", ignoring that the full quote is "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. _Yet we should not pass up our opportunities in that critical 3%_"
> The only real tangible benefit to cloud that I've seen is that a team can instantly provision hardware, database, etc. resources without much planning. That's it. And is that worth it? (I don't really think so.)
Yes! Maybe not for you or me, but it’s definitely worth it to tons of organizations where everyone including engineering was beholden to old school IT departments that take months to spin up a VM after pages of bureaucratic back and forth. The cloud moves it from an IT issue to department budgeting.
The other advantage of cloud was moving capex to opex which the finance people liked because *hand wave* something about amortization. Those are the two reasons most established companies moved to the cloud. It had little to do with the actual cost but how it was spent and who was in charge of doing it.
Having seen the results of everyone being able to spin up a VM (or an EMR cluster, or an EKS cluster) I can say a little more bureaucracy is probably a good thing.
You end up wasting huge amounts of money on resources that are just sitting around idle (no your fancy automation to shut them down won't work because maybe that dev cluster is actually needed at 2am on Sunday. It's an org problem, not a technical problem).
But more importantly you give the cloud providers an excuse to destroy another square mile of pristine forest and build a giant 4 story grey box that wastes enormous amounts of already limited water and energy.
where everyone including engineering was beholden to old school IT departments that take months to spin up a VM after pages of bureaucratic back and forth. The cloud moves it from an IT issue to department budgeting.
My F500 company put a stop to that. There is new paperwork in place to requisition cloud resources. The bureaucracy will not be replaced.
Even the startup I worked at in my last job didn't let people just spin up whatever resources they felt like in AWS. Changes had to go through architecture/security review, and I might have been the only SDE who was allowed to log into AWS at all. We were subject to SOC 2, but I imagine it's relatively common for SaaS companies to have some kind of compliance framework assuming they want F500s as customers?
> old school IT departments that take months to spin up a VM after pages of bureaucratic back and forth.
Virtual machines were the bureaucracy shortcut. People sounded exactly like you. In fact, you can go back about 30 or 40 years and each decade people said the same type of thing. E.g.:
"What's great about a mainframe logical partition is that we don't have to do a year of paperwork to get our own mainframe."
"What's great about Intel servers is that we don't have to beg IT for a mainframe LPAR."
"What's great about virtual machines is we don't have to... "
"What's great about the cloud is we don't..."
"What's great about SaaS is..." <- You are here.
PS: There's products starting appear in the market that "firewall" SaaS products to stop people like you. Not the hackers. You!
> This is the biggest nasty secret about cloud (and SaaS for things you don't build in-house).
Yep. Huge amounts of marketing funds are spent tricking decision-makers into thinking that off-the-shelf, plug-and-play solutions exist for their idiosyncratic business problems and schemas.
Sometimes such products exist, but they are so bloated with features to support the other 99% of customers. So you absolutely need at least one expert to unwind the complexity.
It's known that "greenfield" software development is much easier than "brownfield"/migrations. It should also be widely known that brownfield SaaS integrations are troublesome, because it involves enormous software+data work to link the existing in-house interfaces to the third-party interfaces. As a rule of thumb, there is no such thing as "off-the-shelf". You WILL have to hire and build and deeply understand your business processes.
> Your headcount requirements are not going to go down because of cloud.
Depends on how big you are. I'm one person and I do a lot of things with the cloud that I could not do if I had to rack servers (or even order dedicateds).
Same goes for small 5-10 person teams that are good with Terraform. I've seen some orgs punching waaaay above their weight given their size. Not possible without classic IaaS.
> do a lot of things with the cloud that I could not do if I had to rack servers
It's not a binary choice between cloud and physical racks in a data center. There is a wide range of options. Companies like Hetzner enables you to click a button and get a dedicated instance, while Digitalocean can provide you with a VM. Both options are cheap and doesn't require much time.
If you do this often, you probably also have an ansible setup to install the base software (like k8s or a simpler stack), you are ready to go within minutes. Just like you would have a terraform config for your cloud
Being able to put everything into (good) source with all the lessons we have about how to manage source code over time puts incredible power into teams that can handle it.
Virtual Machines becoming sufficiently performant is a technical reason for it to exist. It's far less viable if we didn't get vmx and related extensions to the x86 command set.
Having done both cloud and on prem. It’s soo much more than that. Pace of innovation increases with cloud as you no longer have product beholden to the infra team jira hell.
1) "homegrown systems are expensive to engineer, but cheap to run" misses the most important part - how much does it cost to maintain, and how much of a RISK is it?
Homegrown probably means you're depending on tribal knowledge from a few core people who if they leave you're hosed. That's a risk. You also have to train EVERYONE you hire to learn the homegrown systems, instead of hiring people with externally transferrable skills that can come in and hit the ground running.
2) all of the on-prem folks had to additionally take on that responsibility
Most transitions/migrations always end up with a period where you have both systems running. It's not surprising that at first everyone has additional responsibilities. It sounds like the "on-prem folks" either didn't have the skills to work in the cloud or refused to learn, and needed external hires. Well, that's one way to put themselves out of a job, and that would be the next step once the homegrown system is deprecated.
Obviously there's a reason why "not invented here" syndrome exists. There's a reason "build vs buy" is a complex discussion because of more than just buy costs. People always prefer the home-grown thing, DIY. Engineers especially. On this site, particularly. And, also, plenty of successful businesses exist by cutting out layers and going on a shallower stack ("your margin is my opportunity").
But at the end of the day, for the vast majority of businesses, companies, and software shops, managing their own in-house infrastructure is a worse decision than paying a cloud vendor.
> Homegrown probably means you're depending on tribal knowledge from a few core people who if they leave you're hosed.
there's so much complexity and tribal knowledge with cloud deployments that if tomorrow our cloud experts leave we're also very definitely hosed too, despite everything being documented thoroughly. I'm involved in a product that leverages a cloud-based metaverse system (Mozilla Hubs) that recently had organisational changes requiring us to change our hosting approach, and it's taking the better part of a year of work to understand its logic, for something that would have been a non-issue if homegrown & self-hosted.
I see both points but I have to agree with this one, especially if we’re talking small companies. A startup should outsource everything that is outside their core product (but not more than that), so they can focus on making their product top class.
On the other hand as a solo dev `sudo apt-get install postgresql` plus a short tweak of your pg_hba.conf and a quick script to run pg_dump every night is about as much work as setting up a cloud service.
Managed databases provide a lot of useful features, especially if shit hits the fan. I'm not saying you shouldn't use them. But the work you put into reasonable self-hosted services and reasonable managed services often scale at a surprisingly similar pace.
Firebase is ready to go without me thinking of the details.
If I'm using Flutter or React, I already have a nice client side sdk to use.
The 12th of never when I need to scale it I can switch to a different stack. Firebase functions allows me to do some server side data manipulation.
That said, if I was at work and needed to propose something I'd probably spend more time thinking of this. But for all my side projects firebase is my goto.
Let's just say we're having a competition to see who can crank out a basic crud app first. You're not beating me with Flutter and Firebase.
That is a big “IF” . 99.99% side projects are not successful, you should not be planning architecture expecting to win the lottery .
Even if you did, on premise self-hosting does not save from scaling costs or problems .
If you are successful with firebase , all you get is the bill, firebase will definitely scale without sweat or intervention, for most businesses (side or small) that is better tradeoff .
If you are successful with a self hosted solution , you are likely to be down when the peak traffic or hug of death hits that is when you need it most to work, the app will fail.
This is even assuming intimate expertise on how to scale quickly and having many done it many times before with no mis steps and no researching on what to do.
A professionally managed service at firebase level which is shared infra has already both the capacity and code tuned to scale for any one tenant without effort or lag .
Self hosted infra is optimized for cost and usage pattern of one small tenant, no matter how good your scale out skills and autoscaling code is , there is going be a lag between you and something like firebase which will never notice your spike and issues around it.
This is the crux of success behind multi-tenant IaaS and PaaS, the reason Amazon opened up their infra to the world originally.
All the way even to Amazon.com scale of SRE skills and budgets, hosting on AWS will always be better and cheaper for them than using isolated infra only for them given their load pattern fluctuates pretty heavily .
Amazon.com would still run AWS even if was losing money a bit ,because it would make them more resilient and their infra costs cheaper .
The best analogy I have heard is it similar to insurance, works better with more and more users with diverse usage and risk patterns
Coding CRUD and repeating patterns tends to be boring, however writing interesting logic in backend tends to be interesting.
Generated CRUD interfaces with basics like authentication etc is pretty much easy these days, whether Supabase, Hasura, PostgREST style self hostable stacks or just Firebase, even collaborative data structure basics for CRDTs don't need to be built each time and are available out of the box.
Frontend can get repetitive too, a lot of components keep getting built and redone differently, interesting stuff which makes the tech be core part of the product differentiator such as say how WASM is used at Figma is the real interesting part in frontend.
> I'm a bit surprised we haven't seen a new AWS, something like Walmart Web Services.
Don’t know if you have heard but there are these brand new services called Google cloud and Microsoft azure. Not to mention all the legacy saas providers e.g. oracle that existed prior to aws.
You wish! In my experience they just load all the cloud work on to developers. Like, I’m setting up virtual networks, private endpoints, firewalls and what not, because if I don’t there won’t be horrible (I basically knew nothing about networking before I did it and I still don’t know if anything we do is correct in any manner) security but no security.
It’ll bite the company in the ass eventually, or maybe it won’t, but it is what it is.
I don't think it's a secret, I think the idea is it will allow you to be more resilient then a custom solution. Why? If the person(s) who made the custom solution leave, you can't as easily hire a replacement. What's more, hiring immediately effective folks becomes harder, even if those folks who made it don't leave.
It's a tradeoff, but I don't think folks are keeping secrets around it.
Eh, sure but it's not the same person. There are far more people who can "do cloud" than those who genuinely understand distributed systems well enough to build and operate a homegrown data infrastructure.
True, but anyone who's a cheaper hire because they can "do cloud" but not homegrown also represents a sacrifice in terms of what's you get. In terms of your operational capabilities, you'll likely be paying for that with a crisis first where everyone yells at your team because of a problem in your managed provider you can't fix, and you can't get someone from the provider on the line and helpful in a way that gets you out of it faster. So then you'll tack on add a massive yearly support retainer for a response time SLA that's still bad for your business bottom line and support that's not incentivized to prioritize you. I have stories from name-brand PaaS/IaaS companies.
It's like outsourcing (I don't mean offshore, I mean any kind). It can be a reasonable thing to do if you don't pretend you're getting the same thing for less money and really actually plan around that. But people often do pretend it's the same, and the results aren't immediately apparent. And when they're finally blatantly apparent, either the guilty party has cashed out and left, or people don't have enough perspective to point to the real root cause.
I'm not saying building your own infra is generally a good idea of course. It's just that beyond a certain size, for more businesses than you'd think, reliability has to be a core competency you invest in. And homegrown is a lot easier than it used to be because the offerings in terms of tooling and platforms are way better such that you can strategically craft your level of managedness for optimum cost/benefit on multiple criteria.
Everytime I mess up a password, I click the "eye" button to reveal it if I'm alone, so it will likely go into the screenshot.
I type totp code that will be valid for 2 minutes, and they are clear.
I have emails, account numbers and emails.
I have contacts of my network, sites I visits regularly and nick names I use. Sometimes I paste sensitive content in encrypted chats, but hey, now they are in the screenshot.
Then there are nude pics of partners, intimate journaling notes, porn activity, how much I have in the bank, contracts with clients under nda, legal and illegal drugs I order, political alliances, and all the stupid stuff I may do...
THIS. And the moment that the client expresses reservations about this strategy (which your approach to the subject was trying to elicit), you start talking about the alternatives to continued use of Adobe.
You granting someone rights to material you don’t have makes you liable twice right? If your friend lent you his car and you lent it to someone else, you become liable twice not zero times.
You don't have the right to upload your client's product, yet you use software that uploads your client's product.
You're correct that the two conflict, but I think the courts would have a problem with you for using a product that breaches the employment contract you signed rather than rule that Adobe is at fault here.
I think so, you have to pull in the customer and let them know you planning on using the adobe product and since adobe demands they have full access to the customer’s proprietary media they will have to agree to that as well. How that happens I’m not sure? Have them buy an adobe license for you to use? I guess at that point you need lawyers or their full permission to hand over their ideas to Adobe, otherwise you’re gonna be libel if it leaks/gets copied/etc
Having them buy a license would probably work. You could also have this stuff specified in your contract with your employer.
Realistically, businesses will either shrug and be fine with you using Adobe stuff, or they'll find someone else (who still uses Photoshop, but doesn't know or warn about this stuff). I doubt the person hiring artists knows or cares about this stuff until an actual leak takes place.
Like nvidia.