お待たせいたしました、お待たせし過ぎたかもしれません。みんなー!やっと Google Cloud でデプロイのためのマネージド サービスがでてきたよー!!! Cloud Deploy という謎サービスがリリースされました。現在 Preview ながら、実際にみなさんの環境で体験いただけます。以下はその解説ですが、そんなことより早く使いたい!という方はこちらからどうぞ。 Cloud Deploy とはアプリケーションを実行環境へ継続的デリバリー (CD) するためのもの任意の継続的インテグレーション (CI) システムと連携できるCD に関する重要な指標、データが容易に可視化できる現在サポートするデプロイ対象サービスは GKE のみ使い方は 事前に “パイプライン” としてデプロイ先や順序、方法を決めておいてソフトウェアが書けたら成果物を “リリース” としてまとめ最初のデプロイ先( “ター
なんか言及もされたのでアンサー的に書いてみたけど、アンサーには大してなってないな? ってやつです。一部で言及された、競技プログラミング (競プロ) 関係の話。 その前に、「プログラミングの競技」っていろいろあります。 短時間で問題に解答していく型 (ICPC / 情報オリンピック / AtCoder Regular / TopCoder とか)最適解が容易に求まらない問題のスコアを競う型 (SuperCon / AtCoder Heuristic / ISUCON / ゴルフ / ICFP Programming Contest の一部とか)対戦型 (ICFP Programming Contest の一部とか、最近のはあんまり知らないですが RoboCode / Imagine Cup とか)謎解き型 (ICFP Programming Contest で何回かありましたね。 UMIX
こんにちは、qsona (twitter) です。 マイクロサービスアーキテクチャを指向するとき、(主に社内向け)管理画面をそのままサービスごとに作っていくと、マイクロサービスの数だけ管理画面が乱立するという課題があります。FiNC においては、それにより実際に以下のような問題が発生しました。 ユーザの追加/削除や権限管理がとても大変ユーザ(CS対応者)がどこの管理画面を使えばわかりにくい本記事では、 FiNC においてこれらの問題に対してどう対処してきたか、歴史とともに紹介します。 tl;dr各マイクロサービスで管理画面を作ること自体はよい。統一管理画面は開発のコストがかかりワークしなかった認証を中央管理にする権限管理は各サービス固有のドメイン知識だが、中央で一覧/変更できる状態になっていると便利マイクロサービスの横断的関心事への対処は、「標準」を意識する黎明期から、問題が起こるまでFi
こんにちは、NTTの藤田です。 Dockerfileを書くのに疲れた?イメージサイズの縮小で1日が終わった?コンテナの起動が遅すぎる?コンテナ技術と悪戦苦闘する皆様のための新技術、アーキテクチャに依存しないポータブルなバイナリフォーマットと数十μsで起動するsandbox環境を実現する、WebAssembly System Interface(WASI)を試してみました。 WebAssembly System InterfaceとはWASIは、 WebAssembly(WASM)をウェブブラウザ以外の環境で実行するため、 ホストのファイルやネットワークなどの資源に安全にアクセスさせるための仕様です。 具体的には、POSIXに似たAPIが定義されており、WASMのバイナリが、OSが管理する資源にアクセスできるようになります。 WASMは、ネイティブコードなみの速度で動作する、ポータブルなバイ
Cloud Run とはGoogle Cloud Next 18では serverless containers on the Google Cloud Functions infrastructure + GKE Serverless addonと説明されたものですね。 早速、こちらのQuickStartやってみましょう 事前に必要なことプロジェクトを作成する(既存のプロジェクトを利用することもできます。終了後の後片付けを考えると新しくプロジェクトを作っても良いです)プロジェクトのbillingを有効にするCloud Run APIを有効にするCloudSDKのインストール済み/設定済みであることcomponentsのupdateと、beta componentsのinstallが必要です。コンポーネントをupdateするgcloud components updatebetaコンポーネ
とあるスマートフォン向けMMORPGのプロジェクトで、アプリケーションサーバをほぼすべてGKE(Google Kubernetes Engine)に乗っけて動かしていました。 このゲームは、モバイル向けながら、複数プレイヤ間でそこそこリアルタイム性の高い同時プレイができるものでした。同じフィールドを誰かが歩けば、自分が見ている画面でもほぼ同時にそいつが歩いて横切っていく、同じ敵と皆で一緒に戦えば、誰かが繰り出した攻撃が参加者全員の画面に即同期される、もちろんチャットもできる、そんな具合です。今ではさほど珍しくないのかもしれませんが、PCのオンラインゲームのような機能を搭載した、リアルタイム性の高いモバイルゲームでした。 さて、こうなってくると、オーソドックスなWebサーバのような、HTTP/1でリクエスト/リプライを捌く、というサーバだけでは要件を満たすことができません。 複数プレイヤ間で
Running JavaScript in the JVM has been supported for a long time, first with the Rhino engine released in JDK 6 and later with the Nashorn engine introduced in JDK 8. Recently, the Java team published a proposal (JEP-335) to deprecate the Nashorn JavaScript engine with the intention of removing it from future releases of the JDK. Coincidentally, Oracle Labs is now releasing another engine that sup
Native Java Functions really rocks!TL;DR;Java Functions compiled into a native executable using GraalVM reduces cold start times and memory footprint by order of magnitude compared to running on JVM.Native Java Functions performs equal to or better than Go functions in terms of execution time and memory used.Native Java Functions executable runs from scratch base image, thus have a similar size co
If I mention the word Dependency Injection (DI) in Scala, I might receive a lot of negative responses. This is largely because: Understanding the concept of Inversion of Control (IoC) is still difficult. To fully understand its real benefits, we also need actual coding experiences of using some DI framework.People recall bad experiences when using the Cake Pattern, or they might have suffered from
Analyzing and creating Design Patterns using Functional Programming concepts for your own good. There are many things I’ve been willing to write about this past few months. I figured some talk about Design Patterns combining OOP and FP would be a really great place to start. In this post we will explore a variation of the Builder Pattern commonly known from the GoF book using some Functional Progr
SaaSに代表されるようなB2B向けサービスを展開する上で、顧客セグメントの広げ方(いわゆる山の登り方)は資金の少ないスタートアップにとって、極論すると生死を分かつ程、大きな戦略判断になる。 その判断において、エンタープライズ(大企業)、それともSMB(中小企業)から山を登るか?は1つの顧客セグメントを切る軸として重要な判断軸となる。なぜなら、(超一般化すると)セールスサイクルや獲得コスト、プロダクトの難易度等において、エンタープライズとSMBは違う生き物だからだ。当然のことながら、狙う地域、市場の構造、競合プレイヤーの存在、プロダクト特性によって異なるが、大まかなこの2つの生き物の違いを理解した上で、戦略を考えることは非常に意義のあることだと考える。 そこで今回は、日本の市場全体、そして一般的なエンタープライズとSMBの違い、それにより発生するSaaSの”イノベーションのジレンマ”につい
なぜこの文章を書くか?自身が数ヶ月テックリードの役割で経験した内容を基に、テックリードがどういう役割で、毎日の仕事の中でどのような仕事をするのかについて書いていく。 テックリードはサンフランシスコのWeb系企業では一般的なようだが、日本ではまだそれほど広まっているとはいいづらいと思う。 テックリードに求められるのは一言で言えば”技術でエンジニアチームをリードすること”である。Webエンジニアのキャリアパスでたびたび二元論的に語られる、”技術一本で生きていく”職人的なトラックとも”人やプロジェクトのマネジメントをする”マネジメント系のトラックともニュアンスが異なる。 自身の技術力、そしてリーダーシップをもってエンジニアチームのアウトプットを最大化させていくのがテックリードの役割である。 多くの人にその役割を知ってもらい、エンジニアとしてのキャリア形成の助けになればと思っている。 なお、このポ
SRE視点で見るマイクロサービス FiNC SRE担当の鈴木です。 今回は、以前社内のマイクロサービス勉強会で話した「SREの視点からみたマイクロサービスの運用」に関して紹介していきたいと思います。 いつもは、マイクロサービス万歳みたい… 上記ブログでは2016年1月時点で16個のサービスから構成されていると書かれていますが、2017年5月時点で30個近くまで増えています。増える理由はいくつかありますが大別すれば新機能開発か、既存機能の切り分けという事になります。そんな中でここ1年で取り組んで来た事を紹介していきたいと思います。 Docker/ECSの導入大きな変化の一つは本格的にDockerを本番環境で導入し始めた事です。DockerのマネージメントツールとしてAWSのECSを利用しています。Dockerを利用する事の利点は今更ここで紹介するまでもないですが、新規サービスの立ち上げや既存
Engineering Teamの Akira MAEDA です。 今回はKaizen Platform, Inc.社内にあるエンジニア行動指針を紹介したいと思います。 このエンジニア行動指針は創業間もない頃に技術顧問のNaoya Itoが中心になって作成し、今から2年半ほど前にオフィスに遊びに行った私に、CTOのToshimasa Ishibashi、Naoya Itoの二人がKaizen Platformの実現しようとしている未来とともに熱心に説明してくれ、私のKaizen Platformへの転職のきっかけになったことを今でも思い出します。 以下内容 — - Kaizen Platform, Inc. エンジニア行動指針Message from CEO (Kenji Sudo)・ 我々はクラウドソーシングで新しい働き方を作り出していく集団なんだから、我々自身も新しい組織のあり方に挑戦
IT エンジニアが退職するときに添えられることが多い東亜飯店の画像今月いっぱいで Increments 株式会社を退職します。今日が最終出社日で、残りは有給消化です。 Increments では何をやってたの?Increments と言えば Qiita を運営している会社というイメージですが、Qiita の開発に直接携わる機会はほとんどなくて、技術基盤や Qiita:Team の開発に携わったりしていました。 分かりやすい例を幾つか挙げると、Qiita API v2、トップページのフィード、通知購読、絵文字リアクション、タスクリスト、qiita-elasticsearch、qiita-markdown、アクセス権限付きグループ、サポートサイト、チーム統合機能の開発や、UI 刷新、絵文字画像セット移行、ログインセッション永続化、Docker 移行、VPC 移行、Terraform 導入、We
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く