Code-Wise, Cloud-Foolish

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?

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.

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.