There are things we do for the reward. And then there are things we do just for their own sake, driven purely by internal motivation. It looks like the latter is the case for Julia when it comes to teaching computer things. Being able to choose a lifestyle where you can pursue things that intrinsically motivate you is probably the ultimate form of professional satisfaction. Congrats Julia! I'm really looking forward to see what comes out of this.
Author here. The "monolith" I'm describing is an application-level characteristic. The deployment container, whether it's a bare metal server, a VM, or a Docker container doesn't matter.
I admit that my definition is not necessarily universal, but IMO the characteristics I listed are all highly desirable. I pushed for this model when I worked at Amazon (an AWS service as 1 monolith) and I've seen it work great even at large scale (close to 10K hosts, millions of requests per second, etc).
Obviously money/status matters a lot, but only up to a certain point. Are you able to feed your children right now? Are you paying your bills? If yes, how does getting a raise help with that? You can’t feed your children twice. My point is that we sometimes keep chasing these external rewards without knowing how much is enough. It’s hard to find lasting satisfaction when nothing is ever enough.
It depends on what you want. Satisfaction and peace of mind, or an endless chase for the next reward/recognition/promotion/raise/etc? If the latter, than it’s very important to be effective at getting your work recognized. But if the former, why bother?
Because it doesn’t last. You get a short burst of happiness when you get recognized, but it goes away quickly. Then you start seeking new recognition to make up for the void, and before you know it you’re on an endless treadmill without ever attaining lasting satisfaction.
I think a valid question to ask yourself is: Why do you want to be recognized?
I believe recognition/praise/rewards/etc are not conducive to lasting satisfaction. They feel good for a while, but wear off quickly. OTOH, choosing not to pursue these things is very liberating, and helps you detach your satisfaction from things outside your control.
Germany, Ireland, Sweden, Denmark, Finland, Austria, and Netherlands are some of the most prosperous countries in the world, and they have an open border with 28 other countries — some of which can be easily classified as very poor and undesirable places.
AFAIK, software engineers don't get the 18-month non-compete clause that triggered the cited lawsuit. There's a less harsh clause of 18-months that prohibits working with Amazon customers and vendors. And, there's also a 12-month period where you can't work with any ex-employee who worked at Amazon in the past 12 years. More details in the thread.
Thanks for writing and explaining all of that! I’m sure one way or another there’s a workaround for everything. But my point was exactly that. The fact that you need workarounds hinders agility. I don’t disagree with the benefits.
BTW, about this “What happens when you got millions of connections at once (think slither.io scale)? At the end of the day you have to put it into something that can scale.”
The whole scalability argument of API Gateway and Lambda is highly overrated IMO. There are all sorts of soft and hard limits, and you still have to monitor utilization of concurrency rate and invocation frequency and manually request limit increases when approaching them. Doesn’t sound much different than using EC2.
I’ve seen AWS from inside and I helped build a small part of it. Each individual product is closer to a monolith than a constellation of indispensably deployable jobs/services. The 3 products I worked on were definitely monoliths because we intentionally wanted them to be so. Obviously I don’t mean that they didn’t horizontally scale. Only that the entire app could run from 1 process, the build system produced 1 build artifact, every deployment deploys to all server, and there’s only 1 version of the app running in prod.
My perspective is shaped by my experience developing and maintaining mostly monolithic apps on fleets of servers. I never had the problem of having to manage dozens/hundreds of independently deployable jobs/services. And I hope I never will :) I can see how K8 can be super useful there, but it’s a situation I try to avoid :)
The disadvantages I’m highlighting are about the restrictions of the Lambda abstraction.
What if you want to send telemetry to a third party? Or use a cache? Or deploy something bigger than 250MB? Or handle WebSockets (without having to read/write state in DDB on every message)? Or buffer something on the filesystem? Or run something for more than 15 mins? etc etc.
How do all those things not impact agility? (In the web app/service space at least.)
That was exactly the reason I was very close to adopting Docker recently. But then I realized it was a very rare problem, in my experience. Maybe it’s because I always worked in small teams of <= 10 people, or maybe the stuff I work on tends to not cause local dev problems frequently. But I definitely see how Docker can help a lot there.
Yes, I do the same. For service roles I just use the PowerUser managed role. I don’t see the need to put access control on Amazon’s ability to call it’s own services. I only restrict my EC2 instance profile, since that’s a bit more vulnerable, and I tend to know very precisely what it should have access to.
Author here. Fair. I never used Terraform beyond playing with it briefly, so I can’t really comment on the differences. I tend to choose CFN mostly because I’m familiar with it.
Don’t you have to do it just once though? I have a CloudFormation template that I wrote in 2014 to set up all VPCs, Subnets, Gateways, Security Groups, etc, and it’s still all valid today.
I agree. I have no direct experience with Heroku so I can’t comment on the experience/restrictions, but if a PaaS works well for what you’re doing, I’d go for it.