3 ms·

It depends on the situation, but by keeping a simpler architecture there's not necessarily any overhead. AWS has huge complexity which is a tradeoff against the

It depends on the situation, but by keeping a simpler architecture there's not necessarily any overhead. AWS has huge complexity which is a tradeoff against the complexity of simpler solutions, regardless of the $billing cost.

oneplane 4y ago
That sounds exceptionally vague. Simplicity rarely is bound to some vendor and more likely to be based on requirements and implementation engineering. It mostly gets as complex as it needs to be. Simple things are simple: need IPv4 networking? Get an IPv4 allocation and route it to a (virtual) port of your choice. That is no different between on-prem, managed-dc, unmanaged-dc, managed server provider and cloud provider. There might be some semantics that are different, where a physical port cannot be unplugged via an API (at best you can down/up a switch port but that's not the same) and routing may or may not be implicit, may need a firewall or routing rule and may need translation. But all of that applies always anyway and gets named differently on who you are paying for it. If you create something very complex, but it didn't have to be, perhaps it's simply a bad implementation and not a property of the technology that was applied. There are plenty of engineers that think they can roll their own crypto libraries, write their own filesystems and their own RDBMs... but what business case for the 99% out there really requires that? Nearly everything in a business is a generic problem any business has; it's always about products and/or services, and it's always bound to some legal and financial system the business operates in. Everything beyond that is just marketing and trust building. The only unique thing in most cases is the data you have and the degree of integration of processes within the business. And neither of those are an actual technology problem or complexity driver.

oneplane 4y ago

That sounds exceptionally vague. Simplicity rarely is bound to some vendor and more likely to be based on requirements and implementation engineering. It mostly gets as complex as it needs to be. Simple things are simple: need IPv4 networking? Get an IPv4 allocation and route it to a (virtual) port of your choice. That is no different between on-prem, managed-dc, unmanaged-dc, managed server provider and cloud provider. There might be some semantics that are different, where a physical port cannot be unplugged via an API (at best you can down/up a switch port but that's not the same) and routing may or may not be implicit, may need a firewall or routing rule and may need translation. But all of that applies always anyway and gets named differently on who you are paying for it. If you create something very complex, but it didn't have to be, perhaps it's simply a bad implementation and not a property of the technology that was applied. There are plenty of engineers that think they can roll their own crypto libraries, write their own filesystems and their own RDBMs... but what business case for the 99% out there really requires that? Nearly everything in a business is a generic problem any business has; it's always about products and/or services, and it's always bound to some legal and financial system the business operates in. Everything beyond that is just marketing and trust building. The only unique thing in most cases is the data you have and the degree of integration of processes within the business. And neither of those are an actual technology problem or complexity driver.