
Code-Wise, Cloud-Foolish - forrestbrazeal
https://forrestbrazeal.com/2020/01/05/code-wise-cloud-foolish-avoiding-bad-technology-choices/
======
gingerlime
This makes a ton of sense. I can so totally relate to the emotional attachment
to code you write vs stuff you buy. And also how yaml declarative stuff is a
pain compared to the relative joys of imperative code that does “your thing”,
but it’s better to stick to it.

... but having started reading the good parts of AWS and also in parallel
playing around with cloud66, I have to say, kubernetes (at least the wrapped-
up cloud66 variation) felt compelling. And codeploy and IAM roles and all that
sticky glue? Not really.

Am I falling into a trap?

~~~
streetcat1
The problem with the "clouds" is that there are two types of locks : code lock
and data lock.

The author only talk about code lock. Again, as Kubernetes mature it would
become easier and easier to configure (think of it as unix/linux at its early
days), and hence less and less code locked.

However, Kubernetes does not have data lock. I.e. when you go to the public
cloud, you are locked both in term of compute and in term of data. I.e. the
egress prices are 10x.

------
mikl
Nice cost graph, but you could just as well draw one where the R&D +
development cost ends up being much cheaper in the long run, since the custom
built software engineered to your specific needs ends up being a lot more
efficient.

And there’s certainly cases where using some off-the-shelf cloudy thing pays
off in the long run.

And then there’s the other cases where you find yourself facing a sudden
massive application rewrite because you’ve hit a wall where Elastic Lambda
Magic Beanstalk can’t do something you need and you have to do that custom
solution anyway.

So it’s a nice graph where you put your own favourite solution at the top of
the wisdom curve, but reality is more complex than that. A good engineer will
have to carefully weigh the pros and cons before deciding that Farquaad Simple
Amplified Borealis Service is the right choice. Because while it might be the
right choice today, it may not be tomorrow, and if you’ve built your whole
application around it, you’re going to have a bad time.

Just today I find myself having to scramble to disable a site feature, because
a cloud provider decided to change their pricing model so we would have to get
the extra special gold plan to continue using said feature, and to get gold,
we just had to sign up for a full year contract of 3x our current resource
usage.

If you use a vendor-specific solution like Elastic Lambda Magic Beanstalk,
then you’re basically making a long term bet that the vendor will continue to
support what you’re doing for the lifetime of your app, at a price you can
afford, while continuing to scale it as far as you’ll need. You’ll need to
factor in the risk of that bet into your decisions.

------
dith3r
Those graphs looks like confirmation bias. First of all pay as you go model is
not a simple equation. Most of the time you will cross multiple boundaries and
cost will raise in exponentially way (multiple stories how 30$ changed to
3k$). Secondly there is another bias when CTO has totally different point of
view here are the pain points are. Thirdly, business guy loves to buy product
of the shell to optimize development time where most of software development
methodologies present this period as 20% cost of whole project (most of cost
is located in maintenance (bugfix, alternations, new features). So after quick
release this off shell product most of the times it will limit further grow by
some limitation/cost of usage or missing feature.

