|
there you went and spoiled all the "fun"
To err is human to really elephant it up you need a computer
|
|
|
|
|
So I just had to move some Azure resources from one subscription to another.
Started with my development environment and everything went well.
Did the test environment and everything went to hell.
Application didn't start... Just not at all.
Checked the logs, nothing.
Checked additional logs, nothing.
Checked some other services that I had deployed, all worked.
Did a fresh release from my build pipeline, nothing.
Checked every setting my application needs, nothing.
Did a fresh release from Visual Studio, nothing.
Decided to try a debug build from Visual Studio... And all worked as though nothing ever happened!
Set it back to a release build and all kept working.
Did a re-release from my build pipeline and all is fine.
What the was the problem!?
This thing just cost me a couple of hours, what the , Mickeysoft!?
|
|
|
|
|
Between your post and raddevus', I think Mercury is in retrograde. And maybe more than one planet!
|
|
|
|
|
At first I thought you meant the source control, but that's called Mercurial.
Maybe I should take some distance from programming
|
|
|
|
|
Comfort (or not): I thought that too at the first glance.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
This seems like a situation where you have put something back together, it works, and there are parts left over.
It makes me uneasy.
To err is human. Fortune favors the monsters.
|
|
|
|
|
He didn't sacrifice the right chickens. It will blow up on him in the future.
|
|
|
|
|
I've done that with motorcycle engines.
"What's that spring? Shouldn't it be in there somewhere?"
Engine runs fine, so ignore it.
Gear change return spring: can change up, but not down ... discover this a mile away from home, in top gear. Balls. Did not make that mistake again!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Yes, it feels that way and it doesn't sit right with me either.
Nothing I can do about it anymore though.
Hopefully I'll be able to locate the problem sooner when (not if) it happens again in the future
|
|
|
|
|
Sincerely, I wish you the best of luck there.
To err is human. Fortune favors the monsters.
|
|
|
|
|
Could it be an accidental rebuild all proces clogged in mystery which did the job?
Probably I'm approaching this too simple. No offense (ever) meant
|
|
|
|
|
Mystical elephants disguising themselves as unicorns...again. Fairly certain that is your problem.
There really is no solution for this. Well, there is, but I can't mention it here.
modified 6-Apr-22 12:52pm.
|
|
|
|
|
Slacker007 wrote: There really is no solution for this. Well, there is As an old coworker of mine once said to another coworker "You know what you should do? You should go and get a job in health care."
I guess it would make this problem go away, sort of.
Slacker007 wrote: here I see what you did their
|
|
|
|
|
Sander Rossel wrote: I see what you did their
|
|
|
|
|
My guess is that it thought the build was already deployed in the new subscription.
Same hash, no reason to deploy?
Switching to debug changed all of items so it had to deploy?
|
|
|
|
|
Don't know.
It should've been deployed.
Did the same to my DEV environment without problems, but it broke in TEST.
Maybe the debug build added some missing file that TEST somehow doesn't add.
Who knows, and no way to know now
|
|
|
|
|
This probably isn't very helpful, but your story has further cemented my resolve never to use "the cloud" for development.
|
|
|
|
|
I've had such issues on on-prem servers as well.
Heck, I've had weird stuff like that during debugging on my development machine.
Ask yourself if you're not just a cloud-hater grabbing every opportunity to hate the cloud
|
|
|
|
|
I've also had weird problems like that on my own machine too but I feel (possibly unreasonably) that I have more control when my machine is right here.
|
|
|
|
|
stheller2 wrote: but I feel (possibly unreasonably) that I have more control when my machine is right here. If that's how you feel, let me tell you why you may not want that control and it really isn't about control anyway.
Maybe you'll change your mind about the cloud a little (you don't have to migrate all your projects, but your expectations may be more realistic).
First, imagine having nothing and now you want to run your own web application.
I have a few customers like that.
As a programmer, I can't install servers, but I can create an Azure account and run the web application in an App Service (€65, or about €50 if you only need the basics, or even €5/free if you need it really cheap!).
In fact, running in an App Service on Azure requires me to publish in Visual Studio, which is like three button clicks.
Or I can create (or automatically generate!) a pipeline in Azure DevOps, giving me the option to push my code to Git and have it released automatically.
You could even replace your App Service with an Azure Function (or Logic App) and get 10K executions for free, if it supports your use case.
I'll host a SQL database in Azure while I'm at it (€5 a month for a small one) and my customer has their own web application for about €70 a month.
For that you get daily back-ups, free TLS/SSL certificates, auto-scale, a bit of storage, staging slots (for A/B testing and/or deployment without downtime), the works.
You can, theoretically, run a whole lot of services for just that €70 a month.
If things get too crowded and your app becomes too slow, you can easily scale up.
You'll pay a bit extra each month, but it's a simple button click, rather than migrating an entire server or having downtime because you need to physically update your server.
You could compare those costs to those of a physical server, but remember, App Services are easy and just work.
A few button clicks and you'll have your own CDN (you probably wouldn't want a CDN on your own servers anyway).
No additional configuring required, no updates, no hassle.
These are by far the biggest costs, add a Storage Account, Key Vault, Service Bus, some Function Apps (for short, periodic or triggered code execution) and you'll pay short to nothing extra.
With a Logic App you can easily create workflows that trigger on incoming mail, Tweets, various events in M365, a whole lot, and then process that data and move it to some output (all clickable, your manager could do this!).
This is ideal for my smaller customers, but can just as well work for large customers.
Now take a high-availability scenario.
Using a cloud platform, you can build huge, redundant networks.
Think about mirroring your databases to another continent with automatic failover.
Your files are back-upped to multiple server racks in multiple locations on multiple continents.
This is, of course, all configurable, and the more copies the more you pay.
Using something like Docker, you can have multiple copies of your app running and automatically move your app to another server or even spin up new servers when one fails so your app is ALWAYS online.
Those scenario's are not possible with on-prem architecture for most organizations.
With Azure they become a possibility for even small organizations.
I haven't even started on (big) data possibilities yet.
You get an Azure Active Directory with it for free (that you can sync to your on-prem AD).
And even I, a programmer who knows little about hardware or networks, can make it happen!
So yeah, you give up some control, but that's the power of the cloud.
You could still spin up a VM in Azure and do all the work yourself, but that kind of defeats the purpose of the cloud.
Sometimes there's an outage (doesn't happen a lot, mind you), but your on-prem servers can fail you too!
When an application doesn't start that's often a real pain, but an application failing to start on your own computer is a pain too.
The cloud isn't some magic bullet that solves all your problems, but when people dismiss the cloud so easily they don't know what they talking about.
It's not about "having control", it's about creating business value that you couldn't possibly (or easily) achieve on your on-prem servers.
It's definitely more than just moving your IIS and/or SQL database to the cloud.
Happy to answer any questions you still might have
|
|
|
|
|
I don't develop web applications, so most of that argument, however valid in other cases, doesn't apply to me.
By the same token, I don't run production jobs, just development, so scaling up for bigger production loads doesn't apply to me.
I'm also on a satellite internet connection with a data cap, which makes cloud computing very dubious anyway, especially with the size of test jobs I do run (billions to hundreds of billions of records, hundreds of gigabytes to terabytes of data).
Now what about my available hardware resources?
CPU/memory: My development server, purchased in 2019, has 2x Xeon Silver 4215 with 128 GB of DRAM; my test server, purchased last year, has 2x Xeon Gold 6326 with 256 GB of DRAM.
Storage: My development server has 2.5 TB of Optane SSD, 1 TB of NVMe flash SSD and 1 TB of SATA SSD; my test server has 3 TB of NVMe flash SSD with 1 TB of Optane SSD on the way here from an ebay purchase.
As for big data, my main home server has 2 TB of Optane DC persistent memory, which doesn't seem to be commercially available in the cloud at this time. My test server has 4 TB of Optane DC series 200 persistent memory borrowed from Intel; I'll buy some when it becomes available at a more reasonable price.
I own all of this equipment outright (other than the pmem loan from Intel).
So although I'm not disputing that cloud computing has its place, basically none of its benefits are relevant to my situation.
|
|
|
|
|
In that case it's not so much about "less control".
It also doesn't explain why you have cemented the resolve to never use cloud.
Anyway, in your situation I probably wouldn't use the cloud either.
Doesn't sound like a very good fit.
What do you do, if I may ask?
|
|
|
|
|
Sure. I'm the CTO of 2Misses Corp. We've just received US Letters Patent 11,254,590 for our foundational invention of a heterogeneous hash table and have half-a-dozen other patent applications in various stages of the patent process.
|
|
|
|
|
That's pretty cool and looks really complicated (math isn't my strong point).
It's also far from what I do in every day life (writing custom administrative software for various business clients).
The closest thing I do to what you're doing is probably:
var dict = new Dictionary<string, Whatever>();
employees.OrderBy(e => e.Name);
|
|
|
|
|
Sure, that will do the same thing, just with slightly less scalability for billions of records.
But really most of the complexity in the patent is the incredible detail needed to get a patent that might survive being attacked by big companies with lots of lawyers.
The basic idea is very simple: packing several variable-length records into a fixed-length bucket, so you don't need a pointer to every variable-length record but can instead keep many of those records directly in the table. This saves space (fewer pointers) and time (fewer random accesses to storage or memory).
|
|
|
|
|