I must say as a long time windows developer, .net core on linux is much simpler than on windows. I'm moving everything I have from windows to Linux and the experience, simplicity, speed, stability, etc are much better on linux.
I guess of you're working with gui that's a different story. But for .net websites and background servers, simply use docker on linux and never lool back. And it's much simpler than docker for windows too.
I completely agree. For some reason they're not 100% ssd and that changes everything. That is the main reason I avoid Azure. Last time I tested (about 8 months ago) I got a new windows server instance with 4gb ram and do a windows update. In my laptop takes 20 minutes, aws takes 40 minutes or so, azure takes almost an entire day! Partly this is because MS doesnt keep their images as updated as AWS, but mostly is because HDD instead of SDD as default. Not advocating anything, just my experience.
I find it hard to believe that any decent chipset made in the last decade at least cannot support 32gb of ram. I had a reasonably cheap samsung laptop from 2012 that already did. If apple is not doing it, it's not by the lack of choices in the market.
> It's likely but not guaranteed that n+k was created after n.
This is true in mysql if you rollback a transaction, or use a INSERT INTO ... ON DUPLICATE KEY UPDATE.
In the first, the rollback doesn't revert the sequence, in the second the "insert part" will always increase the number, even if there is a duplicate to update.
I ended up reducing the number of clients. In my case I had a thousand servers, and I was able to change the application structure and merge them into a dozen big application servers. Now with connection pooling each server has less than 100 connections.
As a more permanent solution for scaling, I'm moving out of mysql into something more distributed.
MySql doesn't have a UUID data type, the UUID() function returns a varchar. The way you store it is mostly preference and driver defaults. The C# driver used to handle binary(16) as Guids, then they deprecated that in favor of CHAR(36). But when dealing with a bilion rows, each byte counts and I'll favor binary(16) because it's smaller and that helps with the index sizes and memory usage.
I had some real issues with mysql handling more than 2000 connections. Once past that limit, cpu usage increases exponentially with few connections due to context switching. At 3000 connections, 80% of thr cpu was used gor context switching and it got unusable. That was a 64 core/256gb ram server.
I think it's different. From the docs, this is a one time update to the table. The table itself is not clustered, it's just ordered based on a clustered index, so selects by default should come in that order. But once an insert is done, it's again ouy of order.
Also, an order by using the cluster field most probably invokes an index scan, while a clustered table doesn't.
I use UUIDs in mysql as primary keys in tables with a few million records, and I'm about to migrate a few tables with billions of records from bigint to uuid.
Never saw any real problem. I use char(36), as it's easier to query manually when needed, but I' looking into binary(16) for those billion row tables.
I think most issues with fragmented tables are old problems since ssd, and the overhead is something you will only notice in benchmarks.
If your keys ate supposed to be uuids, the just use them and get the hardware to handle it. In reality, you're most likely to be affected by a zillion other things before an uuid as pk.
If you have a small number of requests over a large period, serverless is cheaper (that includes an api that is idle most of the time and peaks at a very high rate occasionally).
But once you go live and start to grow, there is a point where the lambda cost equals the instance price. And with an instance, you can almost always do a lot more than that number. Again, that will work if your requests are predictable enough that you can see this number consistently over a large period, say, every week at least.
I don't have the numbers here, but I'm pretty sure the same idea applies for serverless. If you have a predictable load, you can always find a much cheaper alternative once you pass a certain threshold. The cloud is never about cost, it's about flexibility.
You're completely right. You can get an amazing server in a very good hosting provider at a fraction of AWS. Really. You can get for $200/month a good server in a good hosting that costs literally $5000/month or more on AWS. Azure and Google are not different.
What you don't get is all their regions, easy scalability with EBS, managed services, etc. But all of that has a very high price, and depending on who you are and what you're trying to do, these cloud providers are probably the worst option.
Please define "very large". When I think large app, I think at least a few hundred endpoints split across tens of thousands of files. How can you have a very large app with a single endpoint? Could you elaborate?
I regret publishing some ideas I had as an open source project. Once it got other people's attention I had so much work trying to document, answer issues and maintain the project that in the end I got tired of it all and had to stop. I really loved the project, but open source is a lot of work, and most of it is not development, but choosing who to give attention, trust, etc, you must be prepared for that. If I kept it for myself I would probably still be working on it and would be using it in my work related projects.
EBS optimized VMs looks nice on paper, you can choose the size and pay for your needs only. But the once you start to use the disk in production you see the problems.
In short, if you want to use the disk a lot, you need to pay a lot. If your app is slow on aws and uses EBS as storage, increase the disk size, not the VM instance type. This is true mostly for database performance, which once the RAM is filled, relies on IO a lot to get new pages from disk.