Function encapsulated as class. Dependencies passed via constructor. Single public method to execute 'function'.
Di as a single class with cake pattern using lazy properties for defining injectable objects. The most important - main function as application entry point.
I'm hosting own MySQL, Mongo and Elastic clusters. At the beginning it takes more time to setup than cloud providers solutions and require more knowledge and tooling to do some ops(upgrades, backups etc). But you know which version of db you are running and how it is configured. Additionally cloud providers own solutions are binding with one of them.
Using Pulumi for about 1 year to manage gcp and AWS environments (5+) - each deployment is around 500 resources. At the begining it was buggy but when they started to add typing i see a lot of improvment.
Please read carefully what I've written. I've never said that struct == class. Secondly Rop Pike wrote under tweet: `But the more important idea is the separation of concept: data and behavior are two distinct concepts in Go, not conflated into a single notion of "class".` which only proves what I presented in first comment.
GO is simple decomposition of OOP, class was split into structure (with composition) and interface(with multiple inheritance without implicit definition what interfaces can can coop with structure). Go only restricted that you cannot define virtual methods.
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.
It depends on many factors. How many requests you predict? What type of application you are building? What size of hot data you will be dealing with? Your workflow is cachable? Dynamic languages are rather unefficient at scale, but allow you to prototype and most of performance comes from proper data structures or algorithms.
So better is to use community fork of Python 2 with new features which are not compatible with Python 2 nor Python 3. Additionally most of public libraries switched to Python 3 and Python 2 will be not supported (and probably will not be compatible with this fork). What are guarantee that this run time will fix issues, security bugs or it will not lose support after a day?
Without any data you will not get any proper advice. Everything is matter of scale, rate and how dynamic your domain is. Sometimes choosing 3rd party is better sometimes creation of own IT.