July 17, 2024 at 12:00 am
Comments posted to this topic are about the item Cloud vs On-premises
July 17, 2024 at 8:44 am
With the benefit of hindsight I see the use of the cloud in the same vein as when a company isn't big enough to have its own dedicated capability so buys in those services. I've worked for companies which didn't have a finance or HR. These were services bought as services as needed.
If a company is successful then it will grow to the point where the workload makes permanent finance and/or HR staff more cost and capability effective.
I've seen the same approach taken when a company wanted to experiment with a particular technology but didn't have the skills in house to deliver a production project. They relied on the contractor market for expertise in building a production system while upskilling their own internal staff.
The unsatisfactory cloud migrations I have seen have generally been lift & shifts, basically treating the cloud exactly like the companies data-centre.
The big three cloud vendors all have their version of the Well Architected Framework. It's basic common sense of the sort that is obvious AFTER you've made a mistake. I'd recommend reading up on it or doing an online course BEFORE (and hopefully instead of) making a mistake.
July 17, 2024 at 2:18 pm
Steve, I've got a question for you about what you said, concerning what workloads might be better suited for a cloud environment. You said:
If you have a variable or growing workload, then the cloud might serve you better than trying to keep up with new hardware in your own data center.
I'm going to embark on a rewrite of an old application that's desperately needed to be rewritten for a long time. As it turns out this app falls into that category, I think. It brings in Federal funds, as it addresses a Federal grant. However, it is only used heavily twice a year, for three to four weeks each time. Then a few weeks afterwards for the managers to generate reports that are sent to the Feds. After that, it sits dormant.
I hope to get access to Azure for some aspects of this rewrite. In particular I had planned on using Azure Key Vault and FeatureManagement. But I hadn't thought of migrating the database to the cloud. Would it be good for me to consider that, especially if I chose to use a PaaS approach, which I think Azure SQL Database uses. Or would it still be best to leave the database on-prem?
Kindest Regards, Rod Connect with me on LinkedIn.
July 18, 2024 at 11:51 am
Rod, your Federal Funds app in the cloud scenario needs exploring.
A large, on-premise database that has very little traffic may not be of concern because it just sits on storage with very low IO. You might change your backup approach during dormant months but for the most part it just sits there not bothering anyone.
Where the cloud becomes useful is when you have to beg, borrow or steal resource just to support the half-yearly usage.
July 18, 2024 at 3:08 pm
Rod,
Here is another option to consider.
Rather than migrating your existing database to Azure SQL, which will involve significant refactoring, instead simply move it to an Azure IaaS VM, which can allow you to leverage your existing Windows and SQL Server license. In our organization, we have a multi-TB data warehouse that started out on-prem, moved to the cloud as an IaaS VM (backup / restore), and then later (for reasons I don't recall) it was moved back to the on-prem data center. During it's lifecycle, it has remained on SQL Server v16 - v19 with essentially no changes to data model or T-SQL code base (related to the cloud migration).
https://azure.microsoft.com/en-us/blog/save-big-by-using-your-onpremises-licenses-on-azure/
Also, Azure VMs bill for compute, storage, and bandwidth separately, so if not used for extended periods of time, you can stop the VM compute service and only pay for the storage of VHD image.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
July 18, 2024 at 3:12 pm
David, I'll answer your last question, first. The impact of my not rewriting the app are profound. One horrible habit that the developers and managers have done over many years, is NEVER upgrade anything, ever. I don't understand their rational, but that's what they've done for years. What its resulted in is a lot of technical debt. And in some cases, such as this app I'll be rewriting, it results in a dead-end for the app. This app has 9 Visual Studio projects within the Visual Studio solution. Its overkill, because the app is comprised of only 12 web pages, and that includes the reports! Its clear to me that several people worked on this app before it fell in my lap. What happened over the years is when someone new came along he/she would use whatever version of the .NET Framework they were working with at the time. So, there are multiple versions used. Now, the application will no longer build. It won't build on my machine and GitHub Actions can't build it either. The versions of the .NET Framework used in it are everything from .NET Framework 2 to 4.5. All of those are no longer supported, so this represents a security risk. It is an example of OWASP's Top 10, in this case vulnerable and outdated components. And this app I'm rewriting is just one example. There's another app, being rewritten by a different team, which is larger with 18 Visual Studio projects within the VS solution, using everything from .NET Framework 2 to 4. And it, too, no longer builds.
As to the other questions you bring up, are good and I admit that I don't know all the answers. I know that when the collect data they'll collect a few thousand data points from around the state. I don't know how many people that is. The database isn't very big. And whoever decided where to put the database, put it on a server with several other databases. I don't know what those other databases are for, perhaps they're all for apps that aren't heavily used on a constant basis. The rest of the questions, I've no idea.
Kindest Regards, Rod Connect with me on LinkedIn.
July 21, 2024 at 7:57 pm
I think the advice above is sound (sorry for the delay).
If you rewrite, I would look at a cloud based db, though mostly because of latency. If you stick close to core SQL functionality, you ought to be able to easily move this to/from a VM to/from Azure SQL. I'd defer the choice as long as possible and stick to features in both SQ L2022 and Azure SQL
July 21, 2024 at 9:41 pm
But I hadn't thought of migrating the database to the cloud. Would it be good for me to consider that, especially if I chose to use a PaaS approach, which I think Azure SQL Database uses. Or would it still be best to leave the database on-prem?
Serverless Azure SQL DB would fit the usage pattern perfectly, in terms of only spinning itself up when needed, but presumably adding retry logic to the app is more coding you'd need to do on top of uplifting to newer .NET frameworks, and there's the user impact and storage costs to consider too. I would personally want a good reason to shift that kind of thing to the cloud e.g. on-prem cost reduction or reducing infrastructure workload, compared to greenfield projects which can be built from the ground up to take advantage.
https://sqlrider.net - My technical blog
July 21, 2024 at 9:45 pm
I like your suggestion, Steve. I've been wanting to rewrite this app for many years, as it has so many weird things about it. Concerning just the database, the people who wrote it originally tried the database like it was just a collection of flat files. None of the tables had any primary or secondary keys. I added primary keys to the tables years ago, but it will take more work to also make them IDENTITY columns. Now that my former boss has retired, I can consider doing that (he refused to allow any of us to every make changes apps). I recently discovered a comment from 2009 written by a developer back then (no one I've ever met) saying that he and others were changing from using XML flat files to a database and that this app was old back in 2009. Anyway, that kinda explains why there are no keys in the database and for the general way they wrote the app to interact with the data.
Rod
July 25, 2024 at 8:15 pm
Serverless is great, because it can autoscale, so you can say 4-8 CPUs rather than provisioning 4 or 8. However, if it turns off, you need good retry logic. The first connection will fail, but it takes 30-60s to come alive, so you need a catch error after that time and then retry without bothering the user.
July 25, 2024 at 10:06 pm
I think it really depends on your database needs, costs, skill set, functionality requirements. My whole career was dealing with on-premise, datacenters. We have all had to deal with the limitations of Disk space, drives, increasing RAM, CPU limitations, failovers, etc. The Cloud provides a somewhat easier solution at a cost of 'leasing’ vs 'owning'. I am part of a start-up that when I joined, we had our data on SQL Server on a VM in Azure and have migrated to a SQL Managed Instance. This allowed for the continuation of using SQL Agent Jobs, across database queries, SQL Mail, etc. For monitoring I have setup SQL Insights. Now we are adding Azure SQL Databases, SQL Elastic Pools (to share resources of the standalone Azure SQL databases and to save monies). Standalone Azure SQL using 'Serverless' Tier and 'Auto-pause' enabled in our non-production environments. Now, you have the ability to setup 'Instance Pools' to save on costs if you have the need for multiple Managed Instances.
I think the biggest difference I have seen is have 'less' control over things that were easily configurable on-premise. For SQL MI, Ex. Can't change the SQL Job Retention History. (Found a work-around with an online script(s) that can do it). SQL Operators is not supported in SQL MI. And for Azure SQL there is no SQL Job Agent. I have setup Elastic Jobs and it seems to be working as a good replacement so far.
The costs of each Azure component can add up quickly. They do offer different models of ways to save on costs. I have enjoyed learning new things in Azure but at the same time miss the configurability and control of having databases on-premise.
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply