コロナウィルス問題に伴う社会情勢により、残念ながら開催できなかったDevOpsDays Tokyo2020ですが、私たちは来年4月の開催に向けて既に動き始めています。
今回はこのスクラムフェス大阪の場を使って、2021年の開催に向けてのKick Offミーティングを公開でおこないます。

開催に向けてのスケジュール的なことから、キーノートスピーカーの選定、金銭面のことまで、包み隠さず公開で議論を致します。
カンファレンス運営の裏側が気になる方にとっては、またとない機会になることかと思います。

議論にぜひ参加したいという方も大歓迎です。
気軽な気持ちでぜひ覗いてみてください。
2021年に向けての最高のKick Offの瞬間を皆様と迎えられることを楽しみにしております！

DevOpsDays Tokyoとは…
DevOpsDays Tokyoは毎年4月に、日本語と海外スピーカーによる英語の2トラックで開催される、日本国内で参加ができる国際カンファレンスです。
DevOpsDaysは東京以外にも世界中の60以上の都市で自発的に開催されています。
ソフトウェア開発、ITインフラ運用、そしてその境界線上にあるトピックをカバーし、特にDevOpsを実現するための自動化、テスト、セキュリティ、組織文化にフォーカスします。​

IT技術を駆使して変化に強いビジネスインフラを実現するスキルを身に着けるために、国内外の最先端の事例とプラクティスを結集します。
海外から第一人者を直接招き、ここでしか手に入らない最新情報をリアルタイムで入手出来ます。​

最先端のテクノロジの活用法はもちろん、先進企業で必要とされてきた背景までも理解し、正しく組織内に展開するための洗練された知見を得られます。

このイベントが日本のみならず、世界のDevOpsプラクティスを共有できる、意義のあるイベントになれるよう、願っております。

Grab a drink, some snacks, and help Alex and Sho wrap-up the conference and live-review the event, speeches, and trends in DevOps,

We'll use Mentimeter to capture your feedback, live on the screen, so make sure to have your smartphones ready.

Alex and Sho will return to provide a recap of the previous day, share audience feedback, etc.

Sho and Alex will discuss the theme of this year's event, provide some logistic info, introduce the sponsors, and get everyone fired up for two days of DevOps!

Simplicity is dead. At least, that’s what never-ending stream of constantly changing software platforms would lead you to believe.

Should you use function-based cloud computing? Platform-as-a-service? What about containers, or is it container orchestration? And this is all before you even get to the software itself, and the layers upon layers of abstractions and packages that need to be considered before even thinking about writing code that serves the business.

We’re in the middle of development technology paradigm shift, living in an adapt-or-die world. But there are a lot of key decisions to make, and I’ve seen a lot of organizations make the wrong decisions and end up down a pretty grave path.

Ultimately, they end up with mission-critical systems that are too brittle to change, and too broken not to. The clever engineers that design the systems eventually leave, and no one else is willing to fix the mess. What seemed like a nice technological win just ended up leaving the organization struggling to maintain the systems, while competitors run laps with better, easier-to-maintain systems.

In this talk, I’ll show how, by continuing to partner with Inedo, you can not only avoid becoming a casualty of this paradigm shift, but how you can out-innovate and demonstrate to the powers-that-be that your software platform will let them run laps around their competitors.

I’ll also talk about my vision for Inedo’s future, including our product roadmap and how we’ll continue helping organizations address constantly emerging technology.

Sneak peek: it’s all about getting back simplicity and creating real value by building software

DevOps tools and practices have traditionally been Linux-focused, which has presented a significant adoption hurdle in Windows-based organizations. Windows sysadmins rarely need to use a command line to do their job, let alone Ruby, Git, or other tools. Although tool vendors have tried to make “Windows versions” of their Linux tools, and Microsoft has tried adding “Linux features” to the Windows, many organizations still view DevOps as a square peg in a round hole.

To bring DevOps to Windows-based organizations, it’s important to not only understand the cultural differences between Windows and Linux, but learn how you can build a process that truly crosses development and operation silos, and doesn’t just become “the DevOps team”.

This is where "WinOps" comes in. WinOps strives to address the same challenges as DevOps, using different tools with a Windows approach.

The best way to learn how to succeed is by failing. But when you can’t afford to lose, the next best thing is to learn from other’s people’s mistakes. I’ve seen a lot of DevOps implementation failures over the years, some even due to my own mistakes. In this session, I will review share stories of failure and success, and what I’ve learned is a surefire way to win at DevOps.

We will open the DevOpsDays Tokyo conference by giving a brief introduction of DevOps, the purpose and goals of the conference, as well as giving some of the sponsors an opportunity to introduce themselves.

Windows and Linux are very different; not just technologically, but philosophically. Tools are a major component to establishing DevOps, and the lack of Windows-centric tools limited early Windows DevOps adoptions as most initial supporting technologies emerged from Linux and open-source communities. WinOps strives to address the same challenges as DevOps, using different tools with a Windows approach.

This talk will be tool-focused, and give an overview of the major tools used in Windows DevOps environments.

DevOps tools and practices have traditionally been Linux-focused, which has presented a significant adoption hurdle in Windows-based organizations. Windows sysadmins rarely need to use a command line to do their job, let alone Ruby, Git, or other tools. Although tool vendors have tried to make “Windows versions” of their Linux tools, and Microsoft has tried adding “Linux features” to the Windows, many organizations still view DevOps as a square peg in a round hole.

To bring DevOps to Windows-based organizations, it’s important to not only understand the cultural differences between Windows and Linux, but learn how you can build a process that truly crosses development and operation silos, and doesn’t just become “the DevOps team”.

DevOps represents a simple idea: increase collaboration across teams while automating processes. Although the concept is relatively new to Japan, American IT organizations have been trying to implement DevOps in recent years: many have found success, while others have seen failure.

One of main causes of failure is adopting the wrong culture. Although companies like Netflix and Etsy dominate the DevOps conversation, most enterprises do not have the same problems to solve, nor do they employee the same types of engineers. Thus simply, attempting to emulate Netflix will often yield failure.

It’s similar in Japan; the culture of Japanese IT organizations are quite different from western companies, and attempting to emulate western DevOps practices will often result in failure and other setbacks.  Thus, in order to be successful with adopting DevOps practices, those practices must first be adapted for Japan.

In this talk, I’ll compare and contrast the unique cultural differences in Japanese IT organizations and discuss how you can adopt DevOps practices that specifically address those.