|
I'll give you a real world example, which was actually my first experience and introduction to Azure.
To obfuscate enough to avoid self-promotion, I'll simply refer to the product as MWC, a .net web-based timeclock system consisting of 4 basic pieces:
0: A small app for clocking in/out designed for touchscreen. Usage for this customer was 60 sites and an average of 5 workstations per site, so a potential for 300+ simultaneous connections. Remember that this is a timeclock, so inputs will be fairly concentrated and predictable.
1: A management portal. Usage in this case was also 60 sites plus several admin workstations. Patterns of usage are again predictable...concentrated in the morning and afternoon.
2: SQL Database
3: SQL Server Reports - This one became necessary due to Azure webapp restrictions plus the tight deadline for the project. (I had a co-worker who couldn't help code, but could do SSRS reports)
So here you have a couple of related web applications that have vastly different needs. (really 3 if you count the reports delivered via the SSRS web portal) Then you have the database which obviously needs connections to everything else. Self-hosting was my first thought, (everything's local and fast) (and under my thumb) but it was out of the question. My network reliability is OK, but not good enough. Considering a webhost, I went shopping. At the time, (probably still do, not sure) MS had a free 90 day trial period so I gave it a shot. Here's how it ended up.
The tiny workhorse web app debuted in the Shared Tier but was quickly bumped to Standard. Cost at the time: est: $50/mth.
The management portal web app started (and stayed) in the Free Tier.
The database tier was S1. I don't remember exactly, but at the time it was around $30/mth.
All told, it was around $90 a month for everything. I realize I could have gone with a cheap php/mysql host but I swore off PHP a project before and even though the prototype was already written in php, I was scrapping it anyway.
To summarize, Azure gives you a lot of flexibility with regards to scaling any component either up or out, ssl was automatic on the web apps, and it just worked. In the end, I found an even better, and cheaper alternative to the original setup...an Azure VM that now runs 2 of these MWC systems plus another half-dozen web apps for other customers. I've got SSRS set to serve out reports (the ones that haven't been ported to DevExpress yet). With the VM, you have complete control of the environment, just list self-hosting. Maintenance is a breeze...just rdc in. If you do go for Azure, especially a VM, you can save a lot of money by paying up front. I paid for (reserved) 3 years up front (at $22.86/month) so it winds up being around $20/month now. I should say that it's not a beast (Xeon E5 @2.3GHz and 8GB on Server 2016) but watching Performance during peak hours shows that it's hardly breaking a sweat. Damn, I've got work to do! Good luck Eddie! 
"Go forth into the source" - Neal Morse
"Hope is contagious"
|
|
|
|
|
There are times when the data that you are dealing with may need to be accessed by others outside of your physical location. Consider the following real-life example. We generate hundreds of thousands of food inspection documents each year with inspections performed using software that we design and maintain. We use C# for coding our software and SQL to store our data. Other states also use our software and produce similar amounts of documents. The USDA wanted to be able to view the documents and associated data without having to contact each state to get the documents that they wanted at any given time. Hosting the data at our main HQ was not a viable solution. Instead, we used Azure to host the data. We make connections to the data from our local on-site software to load the documents and their inspection data into the SQL database at Azure daily. We also have a password-protected web-based interface where authorized users can pull up desired documents, print them out, etc. This was our first truly cloud-based project so there was a lot of learning involved. I suggest that you do NOT attempt to buy a domain through Azure. We could never get the domain name purchase to go through so wound up purchasing elsewhere and then pointing to Azure through custom DNS records. Setting up the custom DNS records and getting everything to work correctly was somewhat complex (because an Azure SSL certificate was also involved), but we eventually wound up with a solution that is a perfect fit for our needs.
“The Ultimate Question: 2b | !2b?”
** I would love to change the world, but they won’t give me the source code **
<*})><
|
|
|
|
|
Because you don't need as much ram as Mauve?
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
|
|
|
|
|
I prefer it for my customers.
Here's my situation, a customer wants an application where they can do A, B and C.
I always propose a web application, as they can easily access it at work, from home, on the road, on their PC, tablet, phone, etc.
In fact, the access on the phone and on the road has been a big issue for some of my clients, so web is a totally valid solution.
However, they're just small companies that do not have servers or an IT department.
Using Azure allows me to run a web application without barely any input from my clients for about €60 a month.
I hook it up to Azure DevOps and I have fully automated build and release pipelines in minutes.
I get a SQL Server database for another €5 a month.
Having some additional services costs nothing extra as they can go on the €60 plan.
My clients do not need to buy a server, they do not need an additional IT-person, they do not need updates or whatever.
I can do it all for them and I don't need physical access to anything, nor VPN or what have you.
The €60 a month isn't an issue for my customers and it gives a lot of ease and flexibility.
Other situations can include hyperscale or very planned or unplanned usage.
For example, I have a customer that has two jobs a day for 12 administrations and a couple of agents, so around 40 jobs in total, but it's a pretty intensive job that can take up to ten minutes (depending on the administration and agent, some only take seconds).
I've chosen an Azure Function, which is serverless (and so "free" if you're not using it) and it just runs about ten minutes a day.
Due to the scaling nature of Functions, it "decides" how many instances to run and within about ten minutes all jobs are done.
That same concept would work for jobs that could trigger at any time, but also couldn't trigger for days.
Do you really want to buy a server for those 10 minutes a day!?
There are plenty of use cases for the cloud, or Azure in particular.
Of course you do need a stable and preferably fast internet connection, but most businesses are already heavily dependent on internet anyway.
|
|
|
|
|
I don't know why people like it.
It's like they took a perfectly good language (C) and pythonized it.
No, thankfully it doesn't use significant whitespace, but I get the impression that whoever designed Rust actually hates the C language family and wants bad things to happen to them.
You can keep this nonsense.
If I wanted training wheels, I'd use VB.
Joy. Yet another language I get to learn enough of simply to port things away into a proper language.
Edited to add: anybody who designs a grammar with this construction "fn main()" needs to have their compiler taken away and forced to use scripting languages until they can prove to the world that they can use context free grammars properly
To err is human. Fortune favors the monsters.
modified 22-Mar-22 6:31am.
|
|
|
|
|
When was the last time you spent 14 days continuous, with no computer, programming or programming type projects?
7 days?
|
|
|
|
|
Why would I do that?
Edited to add: I think I was 7.
To err is human. Fortune favors the monsters.
|
|
|
|
|
Saying that you were investigating it prompted me to also read its documentation more carefully. I got about halfway through and browsed the rest to come to much the same conclusion as you, though I wouldn't be quite as nasty about it. 
HtC wrote: whoever designed Rust actually hates the C language family
Probably so. The author of this rant[^] works on Rust.
HtC wrote: If I wanted training wheels, I'd use VB.
They're hardly the only ones who think people need training wheels--and will tell you that it's for your own good.
Rust's designers must have had bad experiences with C: bugs involving memory leaks, invalid pointers, and critical regions. These things must be addressed, but they do it in a condescending way. Curiously, they don't have classes, only "traits" (similar to Java's interfaces, or multiply inherited pure virtual base classes in C++).
HtC wrote: Yet another language I get to learn enough of simply to port things away into a proper language.
Porting won't be easy. Idiomatic Rust is rather different than C++, say, so a lot of code would have to be reorganized. I think it would be easier to just understand the spec and rewrite from scratch in the target language.
I'm amused that Linux wants to start using it. Talk about a culture clash. C++ would make far more sense, but maybe the Linux crowd also feel that C has abused them.
|
|
|
|
|
Greg Utas wrote: Talk about a culture clash. C++ would make far more sense, but maybe the Linux crowd also feel that C has abused them
It won't happen: Linus hates C++. He thinks that C++ is like a box of chocolates: you never know what you are gonna get.
...
one = 1;
two = 2;
x = one + two; In C++ '+' can be redefined to do whatever you want.
I see his point but any language that doesn't allow you to shoot yourself in the foot occasionally is probably too boring. In the words of Spider-Man: "with great power comes great responsibility" 
Mircea
|
|
|
|
|
Yes, I've read that Linus hates C++. Which is why it won't happen, even though it makes sense. "Don't know what you're going to get" is mostly nonsense. Some naughty C++ code must have triggered him years ago.
|
|
|
|
|
Greg Utas wrote: Some naughty C++ code must have triggered him years ago
Nah, Linus is just a dick.
Software Zen: delete this;
|
|
|
|
|
Mircea Neacsu wrote: In C++ '+' can be redefined to do whatever you want.
I never programmed Forth myself, but a former coworker who was a Forth worshipper (quoting the Scriptures: "Go Forth, and Multiply") showed med how to really obfuscate code: Forth lets you redefine any token. So he redefined '17' to have the value of '5'. That brings the concept of 'off by one' to new levels
|
|
|
|
|
I had a love affair with Forth. When I read Leo Brodie's "Starting Forth" book I fell so much in love with it that I wrote my own interpreter (in MACRO11 - the PDP11 assembler no less). Talk about being young and foolish 
Mircea
|
|
|
|
|
LOL! sorry for cliche but so true.
|
|
|
|
|
Greg Utas wrote: I'm amused that Linux wants to start using it. Talk about a culture clash. C++ would make far more sense, but maybe the Linux crowd also feel that C has abused them.
Linus hates the way some C++ features generate huge amounts of magic code behind the scenes that makes it difficult to reason about low level performance impacts.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
|
|
|
|
|
Anything that's critical to performance has to be measured and can typically be rectified. I think the main problem is that almost all the Unix types are hackers at heart, comfortable with spaghetti code.
|
|
|
|
|
That article (rant) that you mentioned is really interesting & makes a great point about C being not just a language but a protocol (since you have to learn C if you want to make any system calls). That's really a great article. Thanks for sharing.
|
|
|
|
|
In fairness, it was Kent who originally posted that link. It was a fun read that made some good points.
|
|
|
|
|
I started reading the rust documentation -- in the first section it says that by default variables are immutable.
Hokay ... it appears the inventors of the language didn't know what "variable" means and didn't know how to type "dictionary.com" in their browser.
I didn't feel the need to read further ...
|
|
|
|
|
All they did was make C/C++ const the default so that you have use the equivalent of mutable if it's not constant.
|
|
|
|
|
Greg Utas wrote: All they did was make C/C++ const the default so that you have use the equivalent of mutable if it's not constant.
Let's think about this. In a typical program I declare dozens of variables and a handful of constants, and of those variables, probably 0.01% need to be immutable once declared.
So the Rust designers flip that, requiring me to explicitly specify that a standard entity in all programming actually behaves as expected, and the default behavior is an edge case? It's a solution in search of a problem and failing to find one.
OTOH, each new release of C# contains new syntax that is more cryptic, and those designers crow, "with this new syntax you save typing TTWWWWOOOOOOO characters!" like it's the greatest thing in the world.
Clowns to the left of me, jokers to the right ....
|
|
|
|
|
The variables may be immutable, but that just means you can't modify the state of the variable. Strings in dotNet and Java are immutable but you can assign a new value to the variable.
Immutability has huge advantages in multi-processing, whether it be on a single core or multiple cores. These advantages all resolve around proving the code is correct. Note - performance is not an advantage in this case. Since Rust is designed to be a system level language that supports multi-core systems, making all variables immutable greatly simplifies development.
|
|
|
|
|
BryanFazekas wrote: in the first section it says that by default variables are immutable.
Hokay ... it appears the inventors of the language didn't know what "variable" means
One rule I remember from my student days: "Constants ain't, variables won't".
I have experienced the truth of this rule quite a few times.
|
|
|
|
|
Coming from a history of C/C++ & even C#, I too felt the way you do about Rust when I first started looking at it. And, I also felt like the syntax is ugly & odd.
However, if you look at it from the viewpoint of what the Rust developers were actually trying to fix, it is quite amazing.
I think that reading this book is what really opened my eyes to it: Rust for Rustaceans: Idiomatic Programming for Experienced Developers[^]
That books delves into what the problems were that have occurred to C/C++ and how the language and compilers have been manipulated to make them end-all be-all even at the risk of code becoming breakable & unsecure.
But, it's a lot to go into and if you're happy with C then there is no reason you would really look into it. I'm always just curious about what they are really trying to do at the foundations.
|
|
|
|
|
Thank you for that. Maybe it will open my eyes, and even change my mind. I've been looking for good material on Rust.
To err is human. Fortune favors the monsters.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
