Quick Question about Cloud thing...
-
Well someone ask me, "is there any point to migrating to azure" and until proven otherwise I see no reason other than sheer daredevil curiosity... Anyway, I am paid either way... so :rolleyes:
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
At work there is a push to move our web apps to Azure... Can't say I have done it before hence I don't have an informed opinion... Although I can't help but wonder.. if you have a read and write database used by almost any page you serve, wouldn't you say both assertion below are true? - since the DB is read/write you can't spawn multiple copy of it on multiple server - since this one server is used for all your queries, you can't really scale your website Hence, I don't see the point in cloudifying many business app, and certainly ours... Any thoughts and feedback?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
We have found it to be cheaper than trying to maintain our own servers and hiring people to keep them updated, patched, running, etc.
Super Lloyd wrote:
since the DB is read/write you can't spawn multiple copy of it on multiple server
This is true regardless of cloud or not. If you want multiple machines you can use load balancing. I believe load balancing is actually easier in Azure than doing it manually.
Super Lloyd wrote:
the point in cloudifying
For us, we'd rather let someone make sure the servers are patched, up and running, etc, etc. But if that is not important to you than it may not make sense.
Social Media - A platform that makes it easier for the crazies to find each other. Everyone is born right handed. Only the strongest overcome it. Fight for left-handed rights and hand equality.
-
At work there is a push to move our web apps to Azure... Can't say I have done it before hence I don't have an informed opinion... Although I can't help but wonder.. if you have a read and write database used by almost any page you serve, wouldn't you say both assertion below are true? - since the DB is read/write you can't spawn multiple copy of it on multiple server - since this one server is used for all your queries, you can't really scale your website Hence, I don't see the point in cloudifying many business app, and certainly ours... Any thoughts and feedback?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
The db issue you point out with cloud is a main reason micro services have become popular. Each micro service generally has its own db. Designing micro services for an application requires some of the same skills as partitioning a db...you have to break them up such that you minimize the number of db updates required to get your micro services into a consistent state. It can become quite complex and if not done well, can end up in a tangled db mess. Fortunately, I write internal apps, and have only a few thousand users, so have not had to go the micro service route.
-
The db issue you point out with cloud is a main reason micro services have become popular. Each micro service generally has its own db. Designing micro services for an application requires some of the same skills as partitioning a db...you have to break them up such that you minimize the number of db updates required to get your micro services into a consistent state. It can become quite complex and if not done well, can end up in a tangled db mess. Fortunately, I write internal apps, and have only a few thousand users, so have not had to go the micro service route.
Scott Serl wrote:
It can become quite complex and if not done well, can end up in a tangled db mess.
And it's the Latest Shiny Thing, so it's going to be done incredibly badly 99% of the time ... by students who think a single lecture they spent on FarceBok makes them a consultant. :sigh:
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony AntiTwitter: @DalekDave is now a follower!
-
Scott Serl wrote:
It can become quite complex and if not done well, can end up in a tangled db mess.
And it's the Latest Shiny Thing, so it's going to be done incredibly badly 99% of the time ... by students who think a single lecture they spent on FarceBok makes them a consultant. :sigh:
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony AntiTwitter: @DalekDave is now a follower!
That's OK, they gets the codez on QA.
If you can keep your head while those about you are losing theirs, perhaps you don't understand the situation.
-
At work there is a push to move our web apps to Azure... Can't say I have done it before hence I don't have an informed opinion... Although I can't help but wonder.. if you have a read and write database used by almost any page you serve, wouldn't you say both assertion below are true? - since the DB is read/write you can't spawn multiple copy of it on multiple server - since this one server is used for all your queries, you can't really scale your website Hence, I don't see the point in cloudifying many business app, and certainly ours... Any thoughts and feedback?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
We have been using Azure for almost 5 years to host a web-based timeclock system for a client. It consists of 2 web apps and 1 database, all azure services. The decision to 'cloudify' instead of self-host (which we normally do) was based on the nature of the application with the most weight on availability. About two years ago, we added another client for the same system/setup. They weren't as demanding as the original client so I was able to keep them on the free plan with a minimum S0 database. In hindsight, it would have been better and cheaper to have created an Azure VM, hooked it up to a domain name, and hosted the apps from it with the database(s) local. In fact, before the CV hit, I had already scheduled a migration to the new host so that I can save around $100 a month. In addition, the apps perform better and it opens up a lot more options when you have complete control of the hosting environment. The free plans are nice but have limitations. Our biggest pain was finding a reporting tool that allowed printing and exporting in the Azure environment. The quick and dirty way (still being used) was to host the ssrs reports (in anonymous mode) on our webserver and hook them to the azure sql databases...slow, but it works. I'm looking forward to removing that link from the process and use a proper reporting tool. As for scaling, once I have everything running on the VM, if I need more horsepower (not likely) then I can bump it up to the next paid level. (currently costing me around 70 usd/month and more than adequate for what I'm doing now) btw, I'm renting a windows server 2016 datacenter with a moderate 8GB of ram. Obviously, you can save money if you go the 'nix route.
"Go forth into the source" - Neal Morse
-
At work there is a push to move our web apps to Azure... Can't say I have done it before hence I don't have an informed opinion... Although I can't help but wonder.. if you have a read and write database used by almost any page you serve, wouldn't you say both assertion below are true? - since the DB is read/write you can't spawn multiple copy of it on multiple server - since this one server is used for all your queries, you can't really scale your website Hence, I don't see the point in cloudifying many business app, and certainly ours... Any thoughts and feedback?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Super Lloyd wrote:
- since the DB is read/write you can't spawn multiple copy of it on multiple server
- since this one server is used for all your queries, you can't really scale your website
I agree. These two statements contradict each other. I will go further and say that all client/server architectures suffer the same inherent flaw of not being scalable. Can you make them "scale"? Yes, but it is also true that anything can fly if you give it enough power. Hmmm, I wonder what would happen if Azure one day didn't have enough "power"? Hint: not good. Hint2: study the shipping giant Maersk NotPetya hack in Andy Greenberg's book "Sandworm" chapters 20-28. Hint3: think pandemic, only on 'cloudy thing' computers. Hint4: again, not good.
-
At work there is a push to move our web apps to Azure... Can't say I have done it before hence I don't have an informed opinion... Although I can't help but wonder.. if you have a read and write database used by almost any page you serve, wouldn't you say both assertion below are true? - since the DB is read/write you can't spawn multiple copy of it on multiple server - since this one server is used for all your queries, you can't really scale your website Hence, I don't see the point in cloudifying many business app, and certainly ours... Any thoughts and feedback?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
My preliminary calculations are that the cloud costs the same as if we were to buy all new servers every year. The benefits are automatic scaling as needed, and lack of need to maintain hardware. A drawback is controlling costs. With Amazon, it was impossible. With Azure, it's better, but still not good.
-
At work there is a push to move our web apps to Azure... Can't say I have done it before hence I don't have an informed opinion... Although I can't help but wonder.. if you have a read and write database used by almost any page you serve, wouldn't you say both assertion below are true? - since the DB is read/write you can't spawn multiple copy of it on multiple server - since this one server is used for all your queries, you can't really scale your website Hence, I don't see the point in cloudifying many business app, and certainly ours... Any thoughts and feedback?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Using the cloud for any critical corporate data is a fools' errand. Though the vendors will tell you of their great security, nothing is truly secure on the web. And it is made even more insecure by having centralized storage locations such as the Cloud that can host the data from multiple companies all in a single facility or several such facilities. Cloud hosting has been shown to be quite vulnerable to breaches and security specialists have been wary about this type of data storage for quite some time. Cloud hosting marketing is directed at reducing costs, not increasing a company's security. And since so many companies have been shown to not really care all that much about strict security, the Cloud hosting plans make a very tempting alternative to paying additional employees to maintain their own internal storage services along with the corresponding hardware costs. Think about it. If a company deems it worthwhile, it probably isn't...
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com
-
Super Lloyd wrote:
- since the DB is read/write you can't spawn multiple copy of it on multiple server
- since this one server is used for all your queries, you can't really scale your website
I agree. These two statements contradict each other. I will go further and say that all client/server architectures suffer the same inherent flaw of not being scalable. Can you make them "scale"? Yes, but it is also true that anything can fly if you give it enough power. Hmmm, I wonder what would happen if Azure one day didn't have enough "power"? Hint: not good. Hint2: study the shipping giant Maersk NotPetya hack in Andy Greenberg's book "Sandworm" chapters 20-28. Hint3: think pandemic, only on 'cloudy thing' computers. Hint4: again, not good.
The cloud isn't magic. Any of your alarmist scenarios apply to in house hosting also. Except of course that you must then either have already hired and have been paying your in house experts for years to deal with that or do a mad emergency scramble to find a consultant when your servers are taken out. A full service hosting, such as a cloud server, but true of any full service hosting company already has those experts.
-
At work there is a push to move our web apps to Azure... Can't say I have done it before hence I don't have an informed opinion... Although I can't help but wonder.. if you have a read and write database used by almost any page you serve, wouldn't you say both assertion below are true? - since the DB is read/write you can't spawn multiple copy of it on multiple server - since this one server is used for all your queries, you can't really scale your website Hence, I don't see the point in cloudifying many business app, and certainly ours... Any thoughts and feedback?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Super Lloyd wrote:
Although I can't help but wonder.. if you have a read and write database used by almost any page you serve, wouldn't you say both assertion below are true?
- since the DB is read/write you can't spawn multiple copy of it on multiple server
- since this one server is used for all your queries, you can't really scale your website
All of that is irrelevant if the business doesn't have the traffic to require multiple servers. In that case a hosting company (cloud service) is just providing the expertise to keep that single server up an running all the time. You are responsible for the data but not the box, operating system and perhaps not even the database software. But if the business does have enough volume then the business itself drives what the specifics are of how the volume can be handled. If a Point of Sale device is ringing up a transaction in Los Angles then there is no overlap between that transaction and one at the same time in Tampa Bay. The cashier is different, the customer is different, the fulfillment center is different. Same is true for medical, construction, movie theaters, etc. As one design consideration a smaller company can make if they actually have the volume is that replicated servers do not all need to be read and write. It is likely that many more transactions will be reads rather than writes. So most can be read only. That reduces load on the write server, often significantly. Writes are replicated to the read servers. That leads to the design consideration of timeliness. Does a new user that was just created in New York (east coast server) need to actually be visible to the user in California (west coast server) immediately or is 5 seconds later good enough? After all the customer service rep that created that user probably needs to do some stuff before they even tell the user it is working. And that will take more than 5 seconds. Naturally very large businesses have much more complicated design problems that they must deal with. But companies can get by with must less complications for quite a long time before they encounter those problems.
-
The db issue you point out with cloud is a main reason micro services have become popular. Each micro service generally has its own db. Designing micro services for an application requires some of the same skills as partitioning a db...you have to break them up such that you minimize the number of db updates required to get your micro services into a consistent state. It can become quite complex and if not done well, can end up in a tangled db mess. Fortunately, I write internal apps, and have only a few thousand users, so have not had to go the micro service route.
Brilliant explanation! It kills 2 birds with one stone! - how to make scalable Cloud service! - what's the deal with this newfangled micro service thing! :O
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
The cloud isn't magic. Any of your alarmist scenarios apply to in house hosting also. Except of course that you must then either have already hired and have been paying your in house experts for years to deal with that or do a mad emergency scramble to find a consultant when your servers are taken out. A full service hosting, such as a cloud server, but true of any full service hosting company already has those experts.
I see your point and agree. However, I don't think I'm being too alarmist. I don't think the Maersk concern would think I am being too alarmist either. But your point still stands. My bias comes from having developed a decentralized software framework that has the potential of solving the scalability and resiliency issues centralized client/server architectures chronically suffer from. From that viewpoint, clouds look very risky indeed and again, the OPs original statements still stand. Decentralized computing resolves the OP's truth statements.
