The many lies about reducing complexity part 2: Cloud
1–10 of 131 posts
Re: The many lies about reducing complexity part 2: Cloud
#2[deleted]
Re: The many lies about reducing complexity part 2: Cloud
#3Reducing complexity should never be about platform (on-prem vs cloud).
It should be about constructing software in partnership with the business and reducing complexity with modeled boundaries.
You can leverage the cloud to do some interesting things, but the true benefit in is _what_ you construct, not _how_.
Re: The many lies about reducing complexity part 2: Cloud
#4Reducing complexity should never be about platform (on-prem vs cloud). It should be about constructing software in partnership with the business and reducing complexity with modeled boundaries. You can leverage the cloud to do some interesting things, but the true benefit in is _what_ you construct, not _how_.
There is an element of _how_ as well. You could create simple monoliths or overengineered microservices. Or, complex monoliths with heavy coupling vs cleanly designed microservices with clear separations of concern.
Re: The many lies about reducing complexity part 2: Cloud
#5Reducing complexity should never be about platform (on-prem vs cloud). It should be about constructing software in partnership with the business and reducing complexity with modeled boundaries. You can leverage the cloud to do some interesting things, but the true benefit in is _what_ you construct, not _how_.
I honestly believe that hiding complexity behind a closed door does not eliminate it. However, a lot of software and service vendors have a vested interest in convincing people otherwise. And, historically, they've had all sorts of great platforms for doing so. Who doesn't enjoy a free day out of the office, with lunch provided?
It's also much easier to hide complexity than it is to remove it. One can be accomplished with (relative) turnkey solutions, generally without ever having to leave the comfort of your computer. Whereas the other generally requires long hours standing in front of a chalkboard and scratching your head.
Re: The many lies about reducing complexity part 2: Cloud
#6This shared responsibility principle that underlies cloud marketing speak sounds a lot like the self-driving mess we find ourselves in today - I.e. the responsibility boundary between parties exists in a fog of war and results in more exceptions than if one or the other were totally responsible.
We have been a customer of Amazon AWS for ~6 years now, and we still really only use ~3 of their products: EC2, Route53 and S3. I.e. the actual compute/memory/storage/network capacity, and the mapping of the outside world to it. Because we are a software company, we write most of our own software. There is no value to our customers in us stringing together a pile of someone else's products, especially in a way that we cannot guarantee will be sustainable for >5 years. We cannot afford to constantly rework completed product installations.
We strongly feel that any deeper buy-in with 3rd party technology vendors would compromise our agility and put us at their total mercy. Where we are currently positioned in the lock-in game, we could pull the ripcord and be sitting in a private datacenter within a week. All we need to do is move VMs, domain registrations and DNS nameservers if we want to kill the AWS bill.
I feel for those who are up to their eyeballs in cloud infrastructure. Perhaps you made your own bed, but you shouldn't have to suffer in it. These are very complex decisions. We didn't get it right at first either. Maybe consider pleading with your executive management for mercy now. Perhaps you get a shot at a complete redo before it all comes crashing down. We certainly did. It's amazing what can happen if you have the guts to own up to bad choices and start an honest conversation.
I would also be interested to hear the other side of the coin. Who out there is using 20+ AWS/Azure/GCP products to back a single business app and is having a fantastic time of it?
Re: The many lies about reducing complexity part 2: Cloud
#7Anyone manage to find part 1? It's not on their site, can't seem to find it.
Re: The many lies about reducing complexity part 2: Cloud
#8Isn't this just Jevon's Paradox applied to software?
when technological progress ... increases the efficiency with which a resource is used .., but the rate of consumption of that resource rises due to increasing demand [1]
Re: The many lies about reducing complexity part 2: Cloud
#9Reducing complexity should never be about platform (on-prem vs cloud). It should be about constructing software in partnership with the business and reducing complexity with modeled boundaries. You can leverage the cloud to do some interesting things, but the true benefit in is _what_ you construct, not _how_.
There is an element of _how_ as well. You could create simple monoliths or overengineered microservices. Or, complex monoliths with heavy coupling vs cleanly designed microservices with clear separations of concern.
Are microservices meant to separate data too? As in, each service has its own database.
Wouldn't that lead to non-normalisation of the data or a lot of expensive network lookups to get what I want/need?
What is the point of micro services anyway :-)?
Re: The many lies about reducing complexity part 2: Cloud
#10Microsoft summarized it nice [1] :
Advantages of public clouds:
Lower costs
No maintenance
Near-unlimited scalability
High reliability
Advantages of a private cloud:
More flexibility
More control
More scalability (compared to pure on-prem solution)
[1] https://azure.microsoft.com/en-us/overview/what-are-private-...