Fundamentals
Why this?
- ELAG is the best international platform to discuss IT in libraries.
- It shouldn't be about just a few types of software (catalog, discovery, access system, repository).
- I'm curious about how IT is "being done" in other libraries.
| Servers | c. 140 (RHEL) |
|---|---|
| Workstations, phones, tablets, ... | c. 700 |
| WiFi access points | c. 150 |
| LAN ports | c. 3000 |
| Storage capacity | c. 200 TB (SAN storage) |
| White-collars (clerks) | 5 |
|---|---|
| Sysadmins, developers, specialists | 10 |
| Helldesk guys | 5 |
(measured in people, not FTE)
| Opening hours | 24/7 |
|---|---|
| Daily visits | c. 4000 |
Not here
Here (downstairs)
Also here (backplane)
Death Ray(1925)
Death Ray (2017)
You know...
...it's just IT as you know it.
So why should we speak about it?
The devil is in the detail
- To cloud or not to cloud?
- Outsource or insource?
- How to orchestrate and what?
- How to virtualize?
- Software defined storage / networks?
- Containers?
- Complexity?
Let's not isolate ourselves
World doesn't know about our tools.
CKAN shouldn't exist.
We should target broader audience.
There is nothing like PostgreSQL for the RDF.
Orchestration as I see it
ESB and architecture
How it's usually made
How it should be made
Not really Enterprise or Bus anymoreReasons for ESB I've heard
- The ESB Protects Me From Change
- The ESB Allows Me To Orchestrate Services
- The ESB Can Mediate My Data
- The ESB Can Locate My Services
- The ESB Can Do My Routing
- The ESB Can Monitor My Services
Real reason for ESB
There are old, closed-source and/or vendor abandoned software we use.
If you need SOA, use microservices.
We shouldn't depend on those services.Final thoughts
- Functionality should be in (software) libraries, not in services.
- Cognitive load => simplify! Keep it simple, stupid (KISS).
- We can move complexity, but it's still there.