I agree with your sentiment though.
https://gist.github.com/adamwiggins/5687294
Again, like 12factor, it's a collection of themes from around the internet but it also has stood the test of time.
For the record I factor in:
- Hardware depreciation (36mo)
- Power
- People
- DC rent + power
- software licences / support
What we see now is that compute is dropping in price for on prem every year and density is improving. AMD Rome brings incredibly bang for your buck when buying at significant scale.
But it's not comparing Apples with Apples.
It's virtually impossible to accurately factor in the opportunity cost of doing all this yourself but you can potentially hire a bunch of engineers with the savings of going on prem, ymmv
You can never ever recreate the developer experience on prem regardless of your scale, on you can tell if on prem is good enough
It's difficult to put a value on being to pay as you go or suddenly be serving workloads out of a geo close to your users in Cloud where on prem there is always a lead time
Finally whilst the developer experience is better suddenly having to deal with new challenges takes a while to adjust in Cloud, outages out of your control, non predictable performance, poor support, no access to your hardware
TLDR: Cost is hard to define and isn't a zero sum game
- economy of scale, if you are large enough OS is very cost effective - OSS - No vendor lock in
Cons:
- Complexity - Lack of features and higher level abstractions v public cloud
It's frustrating to read people comparing container technologies or worse container schedulers with OpenStack. Apples and oranges.
If you are planning on running containers on premise you need something from managing the IAAS side of things. OpenStack is excellent at IAAS and is the foundation for running higher level abstractions and services on top.
Those folks that run their own private clouds, what services did you add on top of the basic IAAS to make your private cloud a success? High level abstractions or low level services and features?
Single domain will help you with performance
Depreciation: is typically three years for hardware purchased rather than leased. At the end of 3 years the item has zero value thus can be replaced.
Useful life: is hopefully longer and up to five years. So an item is without value but can still be used. More typical with networking hardware than compute.
The other poster who mentioned power consumption is totally correct. It can make sense to renew hardware even before it has fully depreciated in order to get better datacentre density and lower power draw.
This is what is driving most refreshes in my experience.
We are a monitoring company with a side line in being an online marketplace
SWIFT is indeed analogous to S3.
Whilst it is in the interest of the EU to have a trade agreement with UK, the UK does not have a strong negotiating position.
Why would EU member states do anything to help a country that is destabilising the entire EU project.
After the failure of the HP public cloud Openstack needed this validation.
Of course at this scale you provision by prebuilt rack or even by container
"What's the worst culture you have been part of at a company and were you able to change it"
I much prefer
- external security monitoring (there are many vendors) - automated testing in pre production using skipfish/w3af/whatever - static code analysis - penetration testing - responsible disclosure programmes - hackdays
No wonder the guy was burnt out. That number is simply not manageable in any worthwile way.
The rest of the article just reads like someone is CTO purely because when he joined.
The friction with the VP in terms of how the VP executed hints at someone a little out of there depth maybe.
> Inadequate rewards
In my experience it's very rare for someone to leave for a 5% uplift in compensation.
> Awful office space
Bang on the money. What is even worse is when engineers have a great space that gets changed. Always churn after that.
> No self development
Typically the people who say this are the people who are most likely not to get much from free time to learn new stuff. if you are the type of engineer to learn new stuff then formal training and free time is not going to change your ability to pick things up. If you come to me and say I could not learn X because I had no free time, I am generally sceptical.
> Inefficient collaboration
Generally means other teams / people do not recognise what an awesome thing I did. Generally implies your awesome thing was not massively awesome.
> Negative people
Totally true. The most devastating thing that can happen to teams is to have negative personalities.
> Fear of failure
Did not understand this.
> Lack of clear goals
bang on the money.
> Micromanaging bosses
it's different strokes for different folks. Whilst lots of engineers like the freedom to get to the goal by themselves there are some who actually really enjoy the directive style.
> Useless meetings
Is this still an issue in 2014?
> Wasting your team's time
I sort of get this but again it varies per engineer.
And whilst I am personally proud of some of the technical advances made by the broadcaster I am continually troubled by the commercial advantage the BBC has over it's competitors and the massive waste internally. The later I have personal experience of as I spent some time working for the BBC.
[0] http://en.wikipedia.org/wiki/BBC_Worldwide#BBC_Worldwide_pro... [1] http://en.wikipedia.org/wiki/Television_licensing_in_the_Uni...
Sharding is a problem in Postgres and I am sure they will fix the disconnect between how the data is inserted and how it's read pretty soon.
Automatic failover and datacentre awareness are not typical features in Open Source RDBMS, although you some NOSQL solutions may do this for you.
I'm willing to overlook many weaknesses in PG as we get blistering performance and amazing stability combined with features like hot schema upgrades.
But the problem is that devops has gone from being aspirational for many to the de facto for many.
It's the post devops world. There is no devops anymore, just ops.