4 ms·

How you design your system will dictate how easy or hard it is to move. I've always been an advocate of making sure the design is agnostic to where it's running

How you design your system will dictate how easy or hard it is to move. I've always been an advocate of making sure the design is agnostic to where it's running. Problems with moving start coming up if you've tied yourself tightly to specific services, or ways of working. That's not to say you shouldn't use those services, many are really very useful, just be aware of, and have a plan on how to move away from them (if you need to).

meekins 8y ago
This of course depends on how central the app you are building is to your business and how long lifespan you expect. If it's your core product and you expect a lifespan of > 5 years, not getting tied in with a single cloud vendor is smart. Usually that implies some kind of stack where the highest level of abstraction is a set of containers or VMs. But when for example doing software consulting for a company whose core product and business is not software I personally advocate the completely opposite approach: embrace your cloud platform and use the services with biggest value-add (and coincidentally lock-in). PaaS-style services enable very small teams to deliver functionality very quickly and in a robust manner - and managed services allows for keeping them running very cost-efficiently.
- scarface74 8y ago
  This of course depends on how central the app you are building is to your business and how long lifespan you expect. If it's your core product and you expect a lifespan of > 5 years, not getting tied in with a single cloud vendor is smart. Usually that implies some kind of stack where the highest level of abstraction is a set of containers or VMs. Congratulations, now you have the worse of all worlds. You’re paying more for hosting VMs than you would for baremetal at a colo, you’re not saving money by letting the cloud provider do the “undifferentiated heavy lifting” and your developers aren’t moving faster by depending on the cloud providers services.

meekins 8y ago

This of course depends on how central the app you are building is to your business and how long lifespan you expect. If it's your core product and you expect a lifespan of > 5 years, not getting tied in with a single cloud vendor is smart. Usually that implies some kind of stack where the highest level of abstraction is a set of containers or VMs. But when for example doing software consulting for a company whose core product and business is not software I personally advocate the completely opposite approach: embrace your cloud platform and use the services with biggest value-add (and coincidentally lock-in). PaaS-style services enable very small teams to deliver functionality very quickly and in a robust manner - and managed services allows for keeping them running very cost-efficiently.

scarface74 8y ago
This of course depends on how central the app you are building is to your business and how long lifespan you expect. If it's your core product and you expect a lifespan of > 5 years, not getting tied in with a single cloud vendor is smart. Usually that implies some kind of stack where the highest level of abstraction is a set of containers or VMs. Congratulations, now you have the worse of all worlds. You’re paying more for hosting VMs than you would for baremetal at a colo, you’re not saving money by letting the cloud provider do the “undifferentiated heavy lifting” and your developers aren’t moving faster by depending on the cloud providers services.