システムはどこまで内製化できるか - 急がば回れ、選ぶなら近道
どこでも何回も何十回も言われているが、システムを経営の変化に対応させるにはある程度のシステムの開発を内製化すべきである、という論調が強い。この問題は、古くて新しい問題であり、と同時におそらく、いままでとは違うコンテクストで語られることになるような気がしている。ここ１０数年の流れを見れば、内製化の議論はアウトソーシングの流れとそのより戻りの反復運動の繰り返しだといっていても過言ではなかったと思う。近年はむしろ、SI屋さんの全体的な弱体（特に技能として）化とクラウド等によるインフラの導入しやすさと相まって別の背景で語られることが多くなってきている。また、見逃せない背景としては、そもそもの就労可能若年層の減少と、若年層の総体数減少による能力のばらつきの顕在化も強くあげられる。特にシステム開発の供給サイドの問題は、エンドユーザーの内製化の議論においては、今までのコンテクストでは語られることがなかっ
流離ヒ見聞録: RACとpureScaleの違い
私は旅人です。 ふらっと現れて、ふらっと消えます。 気の赴くままに何かを見に行きます。 たまにあなたの前に帰ってきたら、 そのときは見知らぬうたをうたいましょう。 うたに耳を傾けていただけたなら、 きっと私は幸せです。 Oracle RACとDB2 pureScaleはどちらも shared disk型のcluster RDBなのですが、 違いが理解できていなかったので 今日のClubDB2でお勉強してきました。 結論から言うと、クラスタ内の各DBノードの 整合性を取る部分（OracleではCash Fusion、 DB2ではCaching Facility）の置き場所が 違うってことが、最大のポイントでした。 両製品ともに、あるインスタンスが落ちても、 クラスタ内の他のインスタンスが生きていれば 無停止でDBが稼動するというのがウリです。 ですが、そのためには、落ちたインスタンスが 掴ん
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
