5 ms·

I've build a couple of startups and sold out, worked for a couple of well known ones as early employees and now reside in an architecture position. This magical

by setq 10y ago

I've build a couple of startups and sold out, worked for a couple of well known ones as early employees and now reside in an architecture position. This magical free time never appears, particularly when your business is suddenly return focused after your capital comes in. The low capital cost of the services your are integrating typically is used as a justification to utilise them more. Then a client comes along dangling a few million quid/dollars etc who wants it somewhere else for regulatory compliance or wants to self host it and you have to turn them away. It's not about making your life easier in the short term, it's about building a solid business foundation and continuation plan and a good DR strategy. A lot of people don't consider this and crash and burn and it's not pretty. Edit: your approach is known among my circles as the "Ferengi badass" approach.

discordianfish 10y ago
> This magical free time never appears, particularly when your business is suddenly return focused after your capital comes in. The low capital cost of the services your are integrating typically is used as a justification to utilise them more. Never talked about magical free time, I'm talking of not having to dedicate an ops team to maintain your bare metal infrastructure. > Then a client comes along dangling a few million quid/dollars etc who wants it somewhere else for regulatory compliance or wants to self host it and you have to turn them away. How do you imaging this being easier with a bare metal infrastructure than one on AWS? It really depends on the specifics: If you're using managed services and the customer wants a on-site solution, you need to find replacement for those. If your customer needs something geographically close, deploying to another region is trivial compared to building our a DC suite. > It's not about making your life easier in the short term, it's about building a solid business foundation and continuation plan and a good DR strategy. A lot of people don't consider this and crash and burn and it's not pretty. Indeed, and depending on the specifics it might be much more reasonable to run in the cloud.
- setq 10y ago
  I explicitly mean IaaS not bare metal as the target. IaaS is portable. PaaS is not. I wouldn't have an ops team.
- halomru 10y ago
  >I'm talking of not having to dedicate an ops team to maintain your bare metal infrastructure. You can still build an architecture that works on any of the large feature rich cloud providers with minimal retooling, and that can be deployed on bare metal if needed (minus automatic scaling, load balancing etc.) In the end the trick is to build infrastructure agnostic apps that work on AWS as well as on IBMs cloud
  - setq 10y ago
    This. OpenStack seems to fit that role well.
    - discordianfish 10y ago
      Introducing the complexity of OpenStack just because you might want to migrate off from AWS at some point?
      - setq 10y ago
        No. Use ansible and run simultaneous infrastructure targets in rackspace on openstack and on AWS. Scale one up if the other shits a brick.
    - 0x44 10y ago
      Speaking as one of roughly fifty founders thereof, and also the founder of a (now acquired) startup in the space, it really isn't. The point the OP made about needing an Ops team is magnified by the introduction of OpenStack, and the existence of Rackspace as a (not-quite) provider of OpenStack won't help because their public cloud is going away and there isn't really a replacement as the field consolidated and the consolidated players have shed their OpenStack investments (or are laying off and trying to get away from it). If your goal is to avoid the lock-in to a particular IaaS vendor while avoiding ops overhead, your better bet is to go up-stack and lock yourself into either Cloud Foundry or OpenShift. At least then you'll be able to migrate from IaaS to IaaS semi-transparently, but you are locking into a platform.
- phil21 10y ago
  > Never talked about magical free time, I'm talking of not having to dedicate an ops team to maintain your bare metal infrastructure. At the prices AWS charges this was never a requirement even before virtualization became a thing, much less API-driven cloud environments until you reached such a scale it simply didn't matter. I owned a fully managed dedicated server provider in the late 90's/00's where the customers never even logged into their machines - we handled all that for them and provided what essentially were an early primitive form of infrastructure APIs - FTP, HTTP, SMTP, etc. Certainly complexity has increased, but there are many models between consuming MySQL as a vendor lock-in service, vs. running MySQL on bare metal machines you hand built and racked in your own datacenter. There are far more options than to use the AWS/GCE/etc. "SaaS" offerings that are company specific. I completely agree standing up infrastructure via code is almost a requirement for many businesses these days - I would (and I'm very biased here - I work for a small infrastructure provider) much prefer to see a slightly larger premium being put on solutions that don't promote lock-in. I'm also old and cranky, so seeing things like "resizing jpegs as a service" still makes me think the industry has lost it's collective sanity :) I think my concern is not that you require a set of functional APIs to stand up basic infrastructure - this is certainly very reasonable. For me it's more the direction of the "outspoken self-described leaders" in the industry seems to be towards consuming more application-specific infrastructure services that come with them huge lock-in costs, as well as long-term opex once you hit any form of scale. I'm working on a quote now that is taking a $200k/mo AWS bill down to a $18k/mo co-location bill, where we handle absolutely all networking, hardware, or other "bare metal" related issues for them - they just have us stand up a k8 cluster for them, and we handle the underlying things like monitoring for hardware failure. While certainly not perfect nor as seamless or easy as AWS they largely get similar means to consume their infrastructure, and pay a tenth of the cost. All without hiring any ops folks to deal with servers. However they get to spend 6 months unwinding all the amazon-specific code they now currently rely on, so it's not an easy sell as that cost (both in real dollars as well as opportunity cost) is far more than the savings they will see on this deal through it's lifetime. They are making this move as they see their current lock-in as a long-term strategic risk for the company. Especially as they look at the constant march of increases to opex as AWS bills increase. These are of course my own opinions only :)
  - 10y ago
kondor6c 10y ago
Ferengi badass approach is hilarious! (I really enjoyed it) I also try to urge people when considering a cloud or product vendor that they could expand into your businesses sector and investors or the board could make a decision to avoid that vendor, you will then have to migrate not for technical architecture reasons, but for reasons well out of your control. For example lets say I made a job search application, built on Azure, when Microsoft bought Linkedin the CEO/board of my imaginary company might set out a directive to migrate off of Azure. There are also legal reasons why someone might have to migrate off of a vendor's product, if the two companies get locked in to a lawsuit. When designing these systems I think it is important and not always popular to consider different vendors or a self hosted solution with different hardware vendors. Perhaps more important advocate for an Open Source solution in order to help facilitate a potential migrations or other situations.
- deleted 10y ago
  [deleted]
- deleted 10y ago
  [deleted]
user5994461 10y ago
> Edit: your approach is known among my circles as the "Ferengi badass" approach. Care to explain what that is? Even Google doesn't know.

by setq 10y ago

discordianfish 10y ago

> This magical free time never appears, particularly when your business is suddenly return focused after your capital comes in. The low capital cost of the services your are integrating typically is used as a justification to utilise them more. Never talked about magical free time, I'm talking of not having to dedicate an ops team to maintain your bare metal infrastructure. > Then a client comes along dangling a few million quid/dollars etc who wants it somewhere else for regulatory compliance or wants to self host it and you have to turn them away. How do you imaging this being easier with a bare metal infrastructure than one on AWS? It really depends on the specifics: If you're using managed services and the customer wants a on-site solution, you need to find replacement for those. If your customer needs something geographically close, deploying to another region is trivial compared to building our a DC suite. > It's not about making your life easier in the short term, it's about building a solid business foundation and continuation plan and a good DR strategy. A lot of people don't consider this and crash and burn and it's not pretty. Indeed, and depending on the specifics it might be much more reasonable to run in the cloud.

setq 10y ago
I explicitly mean IaaS not bare metal as the target. IaaS is portable. PaaS is not. I wouldn't have an ops team.
halomru 10y ago
>I'm talking of not having to dedicate an ops team to maintain your bare metal infrastructure. You can still build an architecture that works on any of the large feature rich cloud providers with minimal retooling, and that can be deployed on bare metal if needed (minus automatic scaling, load balancing etc.) In the end the trick is to build infrastructure agnostic apps that work on AWS as well as on IBMs cloud
- setq 10y ago
  This. OpenStack seems to fit that role well.
  - discordianfish 10y ago
    Introducing the complexity of OpenStack just because you might want to migrate off from AWS at some point?
    - setq 10y ago
      No. Use ansible and run simultaneous infrastructure targets in rackspace on openstack and on AWS. Scale one up if the other shits a brick.
  - 0x44 10y ago
    Speaking as one of roughly fifty founders thereof, and also the founder of a (now acquired) startup in the space, it really isn't. The point the OP made about needing an Ops team is magnified by the introduction of OpenStack, and the existence of Rackspace as a (not-quite) provider of OpenStack won't help because their public cloud is going away and there isn't really a replacement as the field consolidated and the consolidated players have shed their OpenStack investments (or are laying off and trying to get away from it). If your goal is to avoid the lock-in to a particular IaaS vendor while avoiding ops overhead, your better bet is to go up-stack and lock yourself into either Cloud Foundry or OpenShift. At least then you'll be able to migrate from IaaS to IaaS semi-transparently, but you are locking into a platform.
phil21 10y ago
> Never talked about magical free time, I'm talking of not having to dedicate an ops team to maintain your bare metal infrastructure. At the prices AWS charges this was never a requirement even before virtualization became a thing, much less API-driven cloud environments until you reached such a scale it simply didn't matter. I owned a fully managed dedicated server provider in the late 90's/00's where the customers never even logged into their machines - we handled all that for them and provided what essentially were an early primitive form of infrastructure APIs - FTP, HTTP, SMTP, etc. Certainly complexity has increased, but there are many models between consuming MySQL as a vendor lock-in service, vs. running MySQL on bare metal machines you hand built and racked in your own datacenter. There are far more options than to use the AWS/GCE/etc. "SaaS" offerings that are company specific. I completely agree standing up infrastructure via code is almost a requirement for many businesses these days - I would (and I'm very biased here - I work for a small infrastructure provider) much prefer to see a slightly larger premium being put on solutions that don't promote lock-in. I'm also old and cranky, so seeing things like "resizing jpegs as a service" still makes me think the industry has lost it's collective sanity :) I think my concern is not that you require a set of functional APIs to stand up basic infrastructure - this is certainly very reasonable. For me it's more the direction of the "outspoken self-described leaders" in the industry seems to be towards consuming more application-specific infrastructure services that come with them huge lock-in costs, as well as long-term opex once you hit any form of scale. I'm working on a quote now that is taking a $200k/mo AWS bill down to a $18k/mo co-location bill, where we handle absolutely all networking, hardware, or other "bare metal" related issues for them - they just have us stand up a k8 cluster for them, and we handle the underlying things like monitoring for hardware failure. While certainly not perfect nor as seamless or easy as AWS they largely get similar means to consume their infrastructure, and pay a tenth of the cost. All without hiring any ops folks to deal with servers. However they get to spend 6 months unwinding all the amazon-specific code they now currently rely on, so it's not an easy sell as that cost (both in real dollars as well as opportunity cost) is far more than the savings they will see on this deal through it's lifetime. They are making this move as they see their current lock-in as a long-term strategic risk for the company. Especially as they look at the constant march of increases to opex as AWS bills increase. These are of course my own opinions only :)
- 10y ago

kondor6c 10y ago

Ferengi badass approach is hilarious! (I really enjoyed it) I also try to urge people when considering a cloud or product vendor that they could expand into your businesses sector and investors or the board could make a decision to avoid that vendor, you will then have to migrate not for technical architecture reasons, but for reasons well out of your control. For example lets say I made a job search application, built on Azure, when Microsoft bought Linkedin the CEO/board of my imaginary company might set out a directive to migrate off of Azure. There are also legal reasons why someone might have to migrate off of a vendor's product, if the two companies get locked in to a lawsuit. When designing these systems I think it is important and not always popular to consider different vendors or a self hosted solution with different hardware vendors. Perhaps more important advocate for an Open Source solution in order to help facilitate a potential migrations or other situations.

deleted 10y ago
[deleted]
deleted 10y ago
[deleted]

user5994461 10y ago

> Edit: your approach is known among my circles as the "Ferengi badass" approach. Care to explain what that is? Even Google doesn't know.