4 ms·

You'd have to weigh or SWOT your decision, using a better product from an unknown company that might offer more or from a trusted company (AWS) that offers less

You'd have to weigh or SWOT your decision, using a better product from an unknown company that might offer more or from a trusted company (AWS) that offers less. Especially if, the unknown company is offering something the trusted company isn't

blowski 9y ago
The thing about "nobody ever gets fired for buying IBM" is that going with an unknown alternative is a risk to you personally and most of the benefits go to the company. When you over-spend on a well-known brand, the company suffers the costs and they barely even notice. The only time they care is if something goes wrong, and then they want to know why you chose an unknown brand.
- akinjide 9y ago
  Say something went wrong, and the company is questioning why you went for an unknown brand. My answer to that would be they offered more value than the trusted brand, also I would have notified necessary stakeholders before making that decision of using services provided by the unknown brand.
  - blowski 9y ago
    Or you could save yourself the risk and all the hassle, and just go with the well-known brand. It's not necessarily what you should do, but it is what often happens.
  - paulcole 9y ago
    > My answer to that would be they offered more value than the trusted brand So much value that things went wrong and now you're explaining yourself.
- singingfish 9y ago
  I figure the correct way is that you build for "the cloud" aka someone else's computer. This means that don't use their proprietary offerings to do so unless absolutely necessary.
  - scarface74 9y ago
    If you don't use their proprietary offerings, you lose most of the benefit of going to the cloud over being on prem. If all you're doing is hosting a bunch of VMs on the cloud, what's the point? Yes, be mindful as a developer I do take a few common sense steps... 1. ElastiCache uses the Memcached protocol so you're really not tying yourself to anything. 2. Lambda - think the "ports and adapters" pattern. Treat your Lambda function as a controller and keep all of your business logic separate. 3. Logging - all of our logging that goes to CloudWatch goes through Serilog. We can switch out the sink easily enough to anything. 4. Simple Queueing System - don't have calls to SQS all over your code, have it in one central module (in our case a Nuget package). 5. Autoscaling - have a shutdown method and wrap the calls that check when your instance is being shut down as events. 6. AWS KMS - We use Hashicorp's Vault and use AWS as a "backend". 7. Cognito - authentication. It's just Middleware for .Net Core that creates a principal before every request. It would be quite easy to add another piece of middleware.
scarface74 9y ago
And if that unknown small company goes out of business, then what? I've been on both sides of that equation - the vendor and the client. When I was working for the vendor, the only way that we were able to secure our biggest deal was to put our entire software stack in escrow -both the proprietary development platform and the system we built for them on top of it. * As the client, part of the contract was that they had to put their code in escrow. In both cases, the client was large enough to negotiate those terms. What if you aren't large enough to force those terms? * That worked out well for me. When the company I worked for went belly up, the client that enforced those terms hired me to complete their system since they had the right to the source code and I was the only person on the planet that was available that knew how both the C based development platform and their implementation worked well enough to complete it.

blowski 9y ago

The thing about "nobody ever gets fired for buying IBM" is that going with an unknown alternative is a risk to you personally and most of the benefits go to the company. When you over-spend on a well-known brand, the company suffers the costs and they barely even notice. The only time they care is if something goes wrong, and then they want to know why you chose an unknown brand.

akinjide 9y ago
Say something went wrong, and the company is questioning why you went for an unknown brand. My answer to that would be they offered more value than the trusted brand, also I would have notified necessary stakeholders before making that decision of using services provided by the unknown brand.
- blowski 9y ago
  Or you could save yourself the risk and all the hassle, and just go with the well-known brand. It's not necessarily what you should do, but it is what often happens.
- paulcole 9y ago
  > My answer to that would be they offered more value than the trusted brand So much value that things went wrong and now you're explaining yourself.
singingfish 9y ago
I figure the correct way is that you build for "the cloud" aka someone else's computer. This means that don't use their proprietary offerings to do so unless absolutely necessary.
- scarface74 9y ago
  If you don't use their proprietary offerings, you lose most of the benefit of going to the cloud over being on prem. If all you're doing is hosting a bunch of VMs on the cloud, what's the point? Yes, be mindful as a developer I do take a few common sense steps... 1. ElastiCache uses the Memcached protocol so you're really not tying yourself to anything. 2. Lambda - think the "ports and adapters" pattern. Treat your Lambda function as a controller and keep all of your business logic separate. 3. Logging - all of our logging that goes to CloudWatch goes through Serilog. We can switch out the sink easily enough to anything. 4. Simple Queueing System - don't have calls to SQS all over your code, have it in one central module (in our case a Nuget package). 5. Autoscaling - have a shutdown method and wrap the calls that check when your instance is being shut down as events. 6. AWS KMS - We use Hashicorp's Vault and use AWS as a "backend". 7. Cognito - authentication. It's just Middleware for .Net Core that creates a principal before every request. It would be quite easy to add another piece of middleware.

scarface74 9y ago

And if that unknown small company goes out of business, then what? I've been on both sides of that equation - the vendor and the client. When I was working for the vendor, the only way that we were able to secure our biggest deal was to put our entire software stack in escrow -both the proprietary development platform and the system we built for them on top of it. * As the client, part of the contract was that they had to put their code in escrow. In both cases, the client was large enough to negotiate those terms. What if you aren't large enough to force those terms? * That worked out well for me. When the company I worked for went belly up, the client that enforced those terms hired me to complete their system since they had the right to the source code and I was the only person on the planet that was available that knew how both the C based development platform and their implementation worked well enough to complete it.