SOFTWARE THAT LASTS
CONTENTS
ABOUT US
TITANOSYS was registered in 2026 by industry veterans in IT
operations. After more than a decade with third-party and open source
tools in pursuit of optimizing company operations, we came away with a
lesson. Nothing seems to last in the second decade of 2000. We have
seen entire software ecosystems come and go. Trends follow other
trends. At the bottom of it, companies whose main livelihood is not
software engineering get the short end of the stick. Just a couple
examples of systems and solutions that came and went:
- Self hosted Microsoft infrastructure - major shift towards Azure and
SaaS offerings
- SCCM - replaced widely by Ansible
- Puppet, Chef, Salt Stack - the current favorite is Ansible, but who
knows tomorrow
- Rundeck - does anyone even remember it?
- Splunk - Elasticsearch, Prometheus and Grafana took over
- .NET - anything but C# these days: Go, Rust, Python
- MS SQL - Postgres, MariaDB (bye bye MySQL)
We could go on, but you already know this from first-hand experience.
MISSION STATEMENT
So how does one create lasting software? What is the guarantee that
something delivered today will last in 2 months? Good design is
fundamental, especially in the age of AI. People can deliver basic
greenfield products in a matter of days with the assistance of AI,
even without background in the sector. However, none of those products
will function for long. Support and maintenance is the most important
for the longevity of products, and AI falters when it comes to
maintaining existing code. It excels at creating new things, but as
soon as it gets to polish, the cracks start to appear.
We bring in-depth industry experience from Cloud, SRE, DevOps across
various principles, such as IaaS, PaaS, SaaS, containerization,
microservices, automation, CI/CD, and more. This experience is used to
design our tools from the ground up with one key thing in mind:
"Could I leave this to my user to self-service?"
If the answer is no, then the solution is just the beginning of
another problem. Products in the 90s were built following the logic of
incremental improvements, such as: "Word 1.0 was great, but in Word 95
you can use graphical elements, hundreds of new formatting features,
and more."
But at the same time, you could say "I am fine with Word 1.0" and you
could basically own and use it forever. That implies control over
several things:
- Supply chain (all the things that are required for the product to
function - you control them, or at least have replicas / backups of
them)
- Stable feature set (you do not have to release weekly patches and
fixes just for your product to not come apart. Whatever your product
shipped with was fully functional from day 1)
- User friendliness (well put together documentation, screenshots,
searchability, clear UI, training if necessary. Anything that needs
recurring consulting or external help to operate is flawed by design)
Our products are built to last. Be it for operations, finance,
compliance or security, if you buy it once, you have it for life. The
only time we apply subscription models is where continuous updates are
the core feature (such as security vulnerability monitoring or
automated patching).
In addition, most of our products are open source, so at any point you
no longer want to pay, you can drill into the code and keep it running
for yourself.
SUMMARY
If you want to take one thing away from this, then let it be:
"TITANOSYS will provide me products that I do not need to replace for
years"
You will hear excuses from others why that is not possible in this day
and age, and we will prove them wrong.
SOFTWARE THAT LASTS
TARTALOM
ROLUNK
A TITANOSYS-t 2026-ban IT uzemeltetesi veteranok regisztraltak. Tobb
mint egy evtized harmadik feles es nyilt forrasu eszkozokkel, a ceges
uzemeltetes optimalizalasa utan egy tanulsag maradt. A 2000-es evek
masodik evtizedeben ugy tunik, semmi sem tartos. Teljes
szoftverokoszisztemakat lattunk jonni es menni. Trend koveti a
trendet. A vegen azok a cegek jarnak rosszul, akiknek a fo megelelese
nem a szoftverfejlesztes. Par pelda rendszerekre es megoldasokra, amik
jottek es mentek:
- Onallo Microsoft infrastruktura - eros eltolodas Azure es SaaS fele
- SCCM - sok helyen Ansible valtja
- Puppet, Chef, Salt Stack - most az Ansible a kedvenc, de ki tudja
holnap
- Rundeck - emlekszik meg ra valaki?
- Splunk - Elasticsearch, Prometheus es Grafana atvette
- .NET - manapsag barmi, csak ne C#: Go, Rust, Python
- MS SQL - Postgres, MariaDB (viszlat MySQL)
Mehetnenk tovabb, de ezt elso kezbol mar ismered.
KULDETET
Hogyan keszul tartos szoftver? Mi a garancia, hogy ami ma kesz, ket
honap mulva is megall? A jo tervezes alapveto, kulonosen az AI
koraban. Alap greenfield termekeket napok alatt le lehet adni AI-jal,
akkor is, ha nincs szakmai hatter. Ezek a termekek viszont nem
mukodnek hosszan. A tamogatas es karbantartas a legfontosabb a hosszu
elettartamhoz, es az AI botladozik a meglevo kod karbantartasanal.
Ujat alkotni tud, de amint a csiszolas jon, megjelennek a repedesek.
Cloud, SRE es DevOps tapasztalatot hozunk: IaaS, PaaS, SaaS,
kontenerizacio, mikroszolgaltatasok, automatizacio, CI/CD es meg tobb.
Ezzel tervezzuk az eszkozoket az alapoktol, egy kerdes menten:
"Ra tudnam hagyni a felhasznalora self-service-kent?"
Ha a valasz nem, akkor a megoldas csak egy ujabb problema kezdete. A
90-es evek termekeit novekvo fejlesztes logikaja epitette, peldaul: "A
Word 1.0 jo volt, de a Word 95-ben mar grafikus elemek es szaz uj
formazasi funkciok vannak."
Ugyanakkor mondhattad: "Nekem jo a Word 1.0", es gyakorlatilag orokre
birtolhattad es hasznalhattad. Ez tobb dolog feletti kontrollt
feltetelez:
- Ellatasi lanc (minden, ami a termek mukodesehez kell - te
kontrollalod, vagy van masolat / backup)
- Stabil funkciokeszlet (nem kell heti patch csak hogy ne essen szet.
Ami kiszallitaskor benne volt, az az 1. naptol mukodott)
- Felhasznalobaratsag (rendes dokumentacio, kepernyokepek,
kereshetoseg, tiszta UI, kepzes ha kell. Ami ismetlodo tanacsadast
vagy kulso segitseget igenyel az uzemelteteshez, az tervezesi hiba)
A termekeink tartosnak keszulnek. Legyen uzemeltetes, penzugy,
megfeleles vagy biztonsag: ha egyszer megveszed, eletedre megvan.
Elofizetest csak ott alkalmazunk, ahol a folyamatos frissites a fo
funkcio (peldaul sebezhetoseg-figyeles vagy automata patcheles).
Raadasul a termekeink nagy resze nyilt forrasu. Ha mar nem akarsz
fizetni, belemesz a kodba, es magadnak futtatod tovabb.
OSSZEFOGLALO
Ha egy dolgot viszel el innen, legyen ez:
"A TITANOSYS olyan termekeket ad, amiket evekig nem kell cserelnem"
Masok mentsegeket mondanak, miert nem lehet ez manapsag. Mi
bebizonyitjuk, hogy lehet.
SOFTWARE THAT LASTS
目次
私たちについて
TITANOSYSは2026年、IT運用の経験者によって登記されました。第三者製とオ
ープンソースの道具で企業運用の最適化を十年以上追い、一つの教訓が残りま
した。2000年代の後半、長く持つものはほとんどありません。ソフトウェアの
生態系ごと現れ、消えるのを見てきました。流行は流行を追います。その底で
損をするのは、本業がソフトウェア開発ではない会社です。現れ消えた仕組み
の例は次のとおりです。
- 自前のMicrosoft基盤 - AzureとSaaSへの大きな移行
- SCCM - 多くがAnsibleに置き換わった
- Puppet、Chef、Salt Stack - 今はAnsibleが人気だが、明日は分からない
- Rundeck - 覚えている人はいるか
- Splunk - Elasticsearch、Prometheus、Grafanaが取って代わった
- .NET - 今はC#以外が多い。Go、Rust、Python
- MS SQL - Postgres、MariaDB(MySQLよ、さよなら)
まだ挙げられますが、あなたはすでに身をもって知っています。
ミッション
では、長く使えるソフトウェアはどう作るか。今日届けたものが二か月後も持
つ保証は何か。良い設計が基本です。特にAIの時代では。AIの助けがあれば、
分野の背景がなくても、基本的な新規製品を数日で出せます。しかし、その多
くは長く動きません。製品の寿命にはサポートと保守が最も重要で、既存コー
ドの保守ではAIはつまずきます。新しいものを作るのは得意でも、磨きに入る
とひびが見えます。
Cloud、SRE、DevOpsの深い経験を持ち込みます。IaaS、PaaS、SaaS、コンテナ
、マイクロサービス、自動化、CI/CDなどです。この経験で道具を一から設計
するとき、鍵は一つです。
「これを利用者のセルフサービスに任せられるか」
答えが否なら、その解決は別の問題の始まりにすぎません。1990年代の製品は
段階的な改良の論理で作られました。例:「Word 1.0は良かったが、Word
95では図形や数百の書式が使える」。
同時に「Word
1.0で十分だ」と言えば、ほぼ永続に所有し使えました。それは次への支配を
意味します。
-
供給連鎖(製品が動くために必要なものすべて。自分で支配するか、少なくと
も複製やバックアップがある)
-
安定した機能集合(製品が壊れないためだけに毎週パッチを出す必要はない。
出荷時のものが初日から完全に動く)
-
使いやすさ(整った文書、画面、検索、明確なUI、必要なら訓練。運用に繰り
返しのコンサルや外部助けが要るものは設計が悪い)
私たちの製品は長く持つように作ります。運用、財務、コンプライアンス、セ
キュリティのいずれでも、一度買えば生涯使えます。継続更新そのものが核機
能である場合だけ(脆弱性監視や自動パッチなど)、購読モデルを使います。
加えて、製品の多くはオープンソースです。もう払いたくない時点で、コード
に入り、自分で動かし続けられます。
要約
一つだけ持ち帰るなら、これにしてください。
「TITANOSYSは、何年も置き換えなくてよい製品をくれる」
今の時代には無理だという言い訳を他から聞くでしょう。私たちはそれを覆し
ます。