What the heck is FinOps? It's controlling cloud spend – and new report says it ain't easy A report from the FinOps Foundation has found that many organisations pay more than they need for cloud services, with challenges including getting engineers to control costs, and too much use of on-demand pricing. The nonprofit is focused on cloud financial management and has members across more than 1,200 companies. It was …
I worked at a company that had a dedicated web server for various web applications they produced for customers. They paid £250/month for it and got well over that in revenue from clients as the hosting cost of their applications. There was nothing wrong with it.
The company knew that the spec of the server was in excess of what they needed. Some (young, inexperienced) "DevOps guru" came in and told them that they could use cloud hosting and save £££
Let me illustrate the problem:
- The previous dedicated server had a fixed, known cost. It was always £3000 per year (250 x 12)
- The cloud server started with an "amazing" monthly price of about £60 in the initial month. Management thought wow, we've saved over £2000 a year since this new one will only cost us £720/year (60 x 12)
- yes, APART FROM..... as they added more applications, the £60/month went up. They never knew what it would be since the calculator for said host seemed to pick numbers out of thin air
- The company charged around £150/hour for development. They spent - no word of a lie - around 70-80 hours moving stuff from one host to another and learning about the new infrastructure. Given their hourly rate the "cost" of this to the company was £12k.
End result: they spent a minimum of around £13k in one year, when something they had previously that was perfectly suited cost them a fixed price of £3k.
If they'd have gone as far as employing a consultant to tell them this, said consultant would have been laughing all the way to the bank!
Good businesses need to know their costs. Having fixed costs is actually good because everyone knows where their stand. The idea that you can "save" with cloud tech simply isn't true for most people especially because no cloud provider factors in the transition cost. If you add in the cost of your FinOps consultant...well...
Exactly the problem. Cloud vendors are in it for profit, not to "help manage your infrastructure." Don't confuse a sales pitch with reality people; reality is you will be billed for every last spin of the platter and every last tick of the CPU clock. It is ALWAYS cheaper to own and provision your own hardware than to lease it. ALWAYS.
For that matter, it doesn't matter WHAT you intend to lease. It will always cost you more than buying because the lease holder still has to do the buying and insists on making a profit on TOP of that.
This post has been deleted by its author
For that matter, it doesn't matter WHAT you intend to lease
Effectively the dedicated server I mentioned in my original post was leased. It was leased from the hosting company, i.e. the company I worked at paid the host £250/month. But here's the thing... that cost is known and fixed. It doesn't matter if we ran nothing on it and it had 0 bytes traffic, or if we ran 100 web applications that maxed out the CPU. The cost was known and didn't vary month-to-month. The existing apps and procedures for running/deploying to that host were known and understood by the employees.
The issues with the cloud are:
1. The costs aren't fixed - or in some cases, even known.
2. The transition / migration costs are extremely high if you factor in how long it takes a company to do it, get their employees up to speed with how it works, and then factor in how much other paid work they could have been doing in this time.
A decade ago The Cloud (TM) was the bee's knees. Everyone was looking to go to The Cloud (TM). Suggesting and promoting cloudy stuff made you a driver, a forward-looker, a visionary.
Now we're getting reports like yours, telling us that The Cloud (TM) is not for everyone nor for everything.
Par for the course, I guess. It's new and shiny, then the grime starts piling on and maybe a bit of rust here and there, and all of a sudden, The Cloud (TM) is not going to seem so shiny any more.
But, of course, not before all of UK Government and the NHS has wasted billions on it.
There is a key difference in starting from scratch vs moving something in to the cloud. Anything can be run in the cloud, but if you have a standard three tier web application (HTML UI, probably produced by a scripting language/Java/C#, an application layer processing events from the UI, and a data store), its unlikely that shifting that to the cloud is going to give you any cost savings.
On the other hand, once you start designing for the cloud, there is opportunity to do things differently. Its common these days (not saying its a good thing) to do JAM stack websites. The actual UI is all generated by JS templates, most commonly React. This can be delivered to the client directly from a storage bucket - you've now got rid of the web server costs, and (pretty much) only pay for the data transfer from the cloud.
Then on to the "A" - APIs. Your typical pre cloud API site was the same as any other webserver hosted tech; you need a webserver, something to program the API in, and a database. Translating that in to cloud optimal solutions, you can go with serverless solutions like AWS Lambda or Google Cloud Functions. Taking Lambda as an example, you pay for the compute time of invoking your lambda and a pittance per million requests - Lambdas + API gateway are an extremely cost effective solution.
One of our services, pre-cloud it required 4 app servers in 2 locations (for reliability + latency reasons), 4 database servers (for the same reasons) and a multi TB chunk of space in the on prem Ceph cluster. - it only served ~100k requests per month, but sometimes quite bursty (nothing, nothing, nothing, 2k requests in 5 minutes). Translating that in to API Gateway/Lambdas/S3, and eliminating the DB entirely, cut the cost from ~$3000 a month into $50. Plus now, it can scale up and down to any level of parallelism - need 1000 workers for the next 30 seconds, it doesn't matter as you only get charged by the number of requests in the billing period.
There's a lot of shit done in the cloud - lift and shift for the app I described would have cost probably much more than $3000 in the cloud. To take advantage of cloud, it has to be written in the "right" way; if you aren't going to do that, or doing so would cost more than your potential savings, then you shouldn't even be thinking of moving it.
This post has been deleted by its author
...~100k requests per month, but sometimes quite bursty (nothing, nothing, nothing, 2k requests in 5 minutes).
So, you could have used SQLite* on two small servers and saved money? It seems to use React on Linux. Seriously, SQLite is quite adequate for a lot of the LAMP sites out there:-
*"... any site that gets fewer than 100K hits/day should work fine with SQLite. The 100K hits/day figure is a conservative estimate, not a hard upper bound. SQLite has been demonstrated to work with 10 times that amount of traffic. The SQLite website... uses SQLite itself, of course...it handles about 400K to 500K HTTP requests per day, about 15-20% of which are dynamic pages touching the database. Dynamic content uses about 200 SQL statements per webpage. This setup runs on a single VM that shares a physical server with 23 others and yet still keeps the load average below 0.1 most of the time."
That was in 2015, I'm pretty certain that the site gets a few more hits since then :-)
Tom, perhaps you didn’t notice the [I’ll get my coat] icon...
But, my reply could be along the lines of "what’s the DR plan for when the server with the "YourServerDatabase of Choice" gets a double disk failure”.
A possible use for SQLite is at my original link: "Systems designers report success using SQLite as a data store on server applications running in the datacenter, or in other words, using SQLite as the underlying storage engine for an application-specific database server... ... For example, the server might have a separate SQLite database for each user, so that the server can handle hundreds or thousands of simultaneous connections, but each SQLite database is only used by one connection.”
On a personal note: I have had some success in setting up temporary structures for the user in a Transaction based on {BEGIN TRANSACTION, CREATE [TEMP] TABLE/VIEW stuff for the user, populate the necessary temp stuff with data subsets, manipulate and check, then update the server tables, DROP whatever, and then do a COMMIT or ROLLBACK}... Another approach is to use ATTACH and DETACH of a separate temporary SQLite file for each user. If you don’t need to write back to the database you can use an in-memory ATTACH, but this does not support transactions.
SQLite was ACID compliant with journaling from about 17(?) years ago. In a crash or power failure the transaction will roll back the next time the file opens - It is possible to corrupt an SQLite database by having another OS process overwriting sectors in the file; by not using appropriate transactions; using a file descriptor after it has been closed; and using an OS file backup without snapshots (The Online Backup API allows incremental backups to other locations, allowing database users to continue uninterrupted while a backup of an online database is made).
OK, I'm retired - My background includes writing stuff with/for the first version of DEC's Rdb; Oracle from V4 (*NIX and Netware); Informix; Postgres; Sybase and then MS SQL Server (from V 4.2), including writing a couple of shrink-wraps which are still in use on 2017 & 2019, some web CGI; and a number of specialised scientific and business systems.
I have indeed found SQLite to be a useful test/prototyping tool, but it is more powerful than many (most?) think. I would almost certainly use it instead of relying on multiple key–value "databases". I hope that I have established that it is more capable than its use for "toys and running tests". Now, if you had said that about MySQL, I might have agreed with you :-)
what’s the DR plan for when the server with the "YourServerDatabase of Choice" gets a double disk failure
One of the read replicas is promoted to master. You can't built a resilient web service around sqlite because you can't scale it across machines and cope with DR.
I'll add another T tho - toys, tests and tools. I use sqlite every day; its great. Its just not the backing store any professional should use for a reliable web service.
"not the backing store any professional should use for a reliable web service" Horses for courses. My idea of a professional is someone who can work within the constraints that exist.
Your mind is made-up, but you can indeed replicate SQLite with commercial and FOSS packages: Dqlite - https://dqlite.io (If you don't mind using Canonical); rqlite - https://github.com/rqlite/rqlite ; SymmetricDS (but more for replicating to bigger databases) ; aergolite - https://github.com/aergoio/aergolite (I have no idea if it's any good) ; LiteSync - http://litesync.io/en/sqlite-synchronization.html (seems to be pricey).
You can advise that something is not suitable for purpose, and if that is not accepted walk away. I was offered a full time government job to create a Lab Information System. The boss, and a panel, asked for a solution to run across 5 laboratories in different parts of the country - My response, based on writing almost identical systems from scratch, and also installing commercial systems was: Either write their own, and staff it appropriately to look after changes and maintenance themselves; or, buy a commercial system and adapt their operation to match it, and not to install their own custom stuff. Experience had shown that once you move away from a "standard" commercial system with your own modifications, future updates would strand you - They wanted to use their in-house skills which were dBase/Clipper for a front-end (It was the early 90s and dBase was approaching obsolescence) and somehow cobble it onto a new commercial Oracle system - I politely told them "No". They offered me a full-time job at deputy director level (Formal interview panels - Apparently they had heard of them), I said no. They asked why - I told them that in my professional opinion their stuff would be orphaned by the commercial supplier. They asked for other alternatives. I thought that as they (like almost all labs) were using spreadsheets extensively, they could continue to use them for local manipulation and display, provided that all of the results were secured and available through a database; and that they should invest in a decent report writer (Not Crystal!) for printed output. They still wanted dBase and Oracle, and seemed to not understand why I wouldn't take a nice government job (I'd been a Scientific Civil Servant before my last salaried job). They went ahead with someone else who was a general programmer. It was a disaster, and after struggling for a few years, his successor installed an off-the-peg commercial system.
I see from your posts that you use Python. I use and like it too, but for heavy lifting on a server I would use it with C (My age is showing, maybe you would like C++). SQLite was originally written to do some quite serious stuff in Tcl and C, including talking to "real" databases. That's why I liked it with PostgreSQL for some of our commercial stuff (As you know great for prototyping, but we realised that it worked well for a lot of stuff by itself). My customer base is probably different - We specialized in $2-20 million p.a. companies, as well as local authorities and smaller government departments. A big database for them increased by "only" 10,000 - 10,000,000 rows p.a., but the data was "important to them, and needed to be right" - Much of the database didn't need to be live, so historical storage in read-only archived tables was preferable (UNION SELECT or UNION virtual table with the live stuff).
-----
OK, some rambling old-fart lessons learned in 50 years of doing this sort of stuff:-
Work for yourself, you'll never be rich or secure as an employee or contractor. If it all goes wrong it's your own fault.
Keep up (highly) specialist skills outside IT, otherwise your work gets outsourced cheaply to someone with generic skills. I'm a Chartered Chemist - Someone told me about 40 years ago that it's relatively easy for a chemist to get IT skills, but not for an IT person to do chemistry - I cheated, I needed to do this stuff in the 1970/80s for chemistry, but a lot of paying work was outside that.
Soft skills are nearly as important as technical nowse. If you can't get on with people you are wasting your and their time.
Microsoft has persuaded most that "only just" good enough is good enough. Computing stuff not working seems to be tolerated by many: Yesterday I was "helping" a younger neighbour to order coffee. The Nespresso web site and App were down for at least an hour, she thought that this was normal. I prefer stuff that works (within the punter's constraints).
Avoid commercial (database) packages whenever possible: Oracle - What do you call an Oracle Customer? A Hostage... Microsoft - That's a lot of SQL Server instances/databases you have there - Congratulations, we have just dramatically changed our licencing (Sorry, it's much more expensive)...
Cheers.
True, but shareholders don't care.
The web server was an investment. The cloud service is a service. Because they don't get in the same column in beancounters' books, shareholders don't like the first one.
They day they will stop to have a short-sighted view, they may realise they are losing a lot of money. But that's not for tomorrow.
You are never going to lease someone's remote hardware and save money by doing so. It will ALWAYS be cheaper to provision your own corporate data center and pay for a WAN pipe, until such time as "per CPU second" billing dies. But that will never happen, because the cloud vendors are NOT altruistic - they are profit hungry businesses who want to take as much of YOUR money for as LITTLE as they can get away with doing or providing.
@Korev, no it doesn't. Because you can buy your own hardware and put it in a datacentre for a fixed price. Or lease a server from the datacentre... for a fixed price.
The key with it is that the pricing is known. Where as with cloud infrastructure the "cost per CPU cycle, read/write operation" and all that bullshit means you can effectively get a bill for £-anything.
A counter argument is that if you lease a dedicated server you don't pay more than your known, fixed cost regardless of whether the server is doing nothing or 100 computationally intensive processes. My original post on this topic sums that up - having a server that's way above the spec the company I described needed was actually significantly cheaper than cloud infrastructure. This was entirely because of the false premise of things like "you only pay for usage", when in fact you also pay to migrate/re-train people etc but this is never advertised by the cloud provider, naturally!
No vendor big or small will ever promote actions that are reducing his revenue. Everytime I hear a vendor mentioning the words "you save" I stop listening right away and do a FF to the end of tape. Detecting the words "only pay for what you use" will make my suspicion even higher.
Ultimately, it boils down to you can buy the hardware and hire the people to manage it or a vendor can do that.
The vendor will always add overhead and profit margins to their costs. Any promotional discounts (by whatever name they call them) will eventually go away and you'll be locked into their service. And don't expect them to have your interests at heart.
If you're a small company that's just starting in the cloud, it might make sense.
If you're a large company (or a government) it only makes sense to the beancounters who are focused on the next quarterly profit (or the next budget allocation).
Things change, things get worse.
In the olden days, when you used to build electronic components, there was a lot of discussion about the risk of using a single micro from a single vendor, that could hold your product to ransom. So the production engineers would always try to find two or more sources for most components. What is worrying now, is the vendor tie in with shit like Lambda, which I believe the BBC has swallowed, which is just microcarching you some things that were usually part of the original bundle.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
