Kilka lat temu usłyszałem ciekawe stwierdzenie. Jakieś 40 lat temu wszyscy szewcy chórem mówili, że ich zawód nigdy nie wymrze, ponieważ ludzie zawsze będą potrzebowali butów, a ktoś będzie musiał je przecież naprawiać. Jak wyszło? Masz dziurę w bucie, to idziesz po nową parę. Niecałe trzydzieści lat temu (tak, to już lata 90-te) tą samą pewność siebie mieli elektronicy. Coraz więcej sprzętu elektronicznego, w każdym sklepie z elektroniką części zapasowe, ktoś to przecież musiał naprawiać.
Około 10 – 15 lat temu to samo myślałem o informatykach i adminach. Coraz więcej serwerów, ktoś to musi ogarniać. Nowe instalacje Apache + PHP + MySQL, nowe aktulizacje Linuksa, ktoś to musi ogarniać. Do tego wykuty prawie na pamięć config Apache, jakieś fajne zmiany w configu i… Dzisiaj okazało się, że taki admin potrafiący zainstalować LAMP to w sumie przeżytek. Admina zastąpiło
docker run --name moja_piekna_strona -p 80:80 \
-v /home/maciej/nicciekawego:/srv \
-d wordpress:latest
Przepraszam. To było 5 lat temu. 4 lata temu ewoluowało do docker-compose:
version: '3.3'
services:
db:
image: mysql:5.7
volumes:
- db_data:/var/lib/mysql
restart: always
environment:
MYSQL_ROOT_PASSWORD: somewordpress
MYSQL_DATABASE: wordpress
MYSQL_USER: wordpress
MYSQL_PASSWORD: wordpress
wordpress:
depends_on:
- db
image: wordpress:latest
ports:
- "8000:80"
restart: always
environment:
WORDPRESS_DB_HOST: db:3306
WORDPRESS_DB_USER: wordpress
WORDPRESS_DB_PASSWORD: wordpress
WORDPRESS_DB_NAME: wordpress
volumes:
db_data: {}
i sieciowca można w sumie zwolnić. A trzy lata temu przeobraziło się w CloudFormation lub, u bardziej ambitnych, w Kubernetes:
apiVersion: v1
kind: Service
metadata:
name: wordpress-mysql
labels:
app: wordpress
spec:
ports:
- port: 3306
selector:
app: wordpress
tier: mysql
clusterIP: None
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mysql-pv-claim
labels:
app: wordpress
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 20Gi
---
apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
kind: Deployment
metadata:
name: wordpress-mysql
labels:
app: wordpress
spec:
selector:
matchLabels:
app: wordpress
tier: mysql
strategy:
type: Recreate
template:
metadata:
labels:
app: wordpress
tier: mysql
spec:
containers:
- image: mysql:5.6
name: mysql
env:
- name: MYSQL_ROOT_PASSWORD
valueFrom:
secretKeyRef:
name: mysql-pass
key: password
ports:
- containerPort: 3306
name: mysql
volumeMounts:
- name: mysql-persistent-storage
mountPath: /var/lib/mysql
volumes:
- name: mysql-persistent-storage
persistentVolumeClaim:
claimName: mysql-pv-claim
Możliwe, że nawet ciut wcześniej. Firmy, które były trochę bardziej do przodu z technologią, po drodze zaadaptowały jeszcze prawdopodobnie Puppet, Ansible lub inne.
Obecnie, aby postawić wordpressa, wystarczy średnioogarnięty devops, który pozmienia w powyższym pliku co ważniejsze parametry i doczyta jak to wgrać w klaster. Zastąpi on admina od baz danych, systemu, LAMPA, sieciowca i po części programistę. Znajomości Apache nikt nie potrzebuje, bo wszystko ogarnia dość dobrze prekonfigurowany Nginx lub load balancer w chmurze, a baza danych w małych instalacjach daje radę. Jeszcze pozostaje kwestia tego, co zrobić z pomieszczeniem po starym WC i zaadaptowanym kiedyś na serwerownie. Jest dobra klima i media, więc możnaby zrobić relax room lub spa. Wróć, spa w biurze średnio pasuje. Więc relax room. A z piwnicy, w której kiedyś trzymało się admina można zrobić garaż dla rowerów.
Wszystko to tylko dla tego, że całą serwerownie i obowiązki admina zastąpiła chmura AWS lub GC ze swoimi usługami baz danych, load balancera, API gateway’ów i całej masy innego fajnego bajeru, który da się prawieże wyklikać. Do tego jeszcze był devops, który spisał to kiedyś w formie Infrastructure As A Code. Już nie pracuje dla nas, ale yaml po nim został 🙂
Co z tym programistą?
Tak, z programistą pewnie będzie podobnie, ale jeszcze nie tak szybko. Co chwilę gdzieś można usłyszeć, że zawód informatyka nigdy nie wyginie, bo kto będzie pisał te aplikacje, strony, bugi i pił kawę w kuchni. Czy na pewno? Można popatrzeć na ostatnie 10 lat rozwoju oprogramowania, na przykładzie Pythona. W 2009 roku dla tego języka było niewiele ORM’ów dla baz danych, kilka fajnych frameworków pozwalających postawić stronę i dość sporo systemowych bibliotek do wszystkiego. Patrząc na to jak rozwinęło się Django, programista dostaje prawie gotowe klocki, z których musi poukładać logiczną strukturę strony, a nie mozolnie pisać logikę, konfigurować renderowanie stron HTML i łączyć wszystko ze sobą. Najpopularniejsze zadania zostały tak zautomatyzowane, żeby programiście pozostało właśnie tylko układanie klocków. No czasami może integracja z czymś innym.
Składając to z zewnętrznymi narzędziami, lub całymi serwisami oferującymi swoje funkcjonalności, programista nie musi nawet konfigurować mailerki do rozsyłania spamu ze swojego serwisu. Maile wyśle za niego sendgrid. Dużo maili wyśle sendgrid za odpowiednią opłatą.
Patrząc na to jak rozwija się świat IT oraz dostępne narzędzia, programistów powoli zastąpią osoby pokroju DevOps, które będą potrafiły szybko poskładać gotowe klocki w całość. Na studiach uczyłem się, że architekt dostarcza UML programistom, z których oni mają wyczytać to, co ma robić aplikacja. Dzisiaj to programista dostaje opis aplikacji, sugeruje klientowi co może być lepiej zaimplementowane i to po prostu robi.
Nie jest to oczywiście reguła, ponieważ jest cała pula aplikacji, które wymagają indywidualnego podejścia, porządnego zaprojektowania i implementacji nieszablonowej logoki. Natomiast ilość aplikacji, które wymagają Javascriptowego frontendu (np. reacta), REST API i bazy danych w chmurze systematycznie rośnie.
Czy zatem programiści to gatunek na wymarciu? Pewnie jeszcze długo nie, tak samo długo jak “zwykli” admini znający system do spodu będą potrzebni. Natomiast same narzędzia, które stają się coraz lepsze i prostsze sprawiają, że coraz mniej aplikacji wymaga programisty z krwi i kości, a coraz więcej akcji dzieje się magicznie i może być mocno uproszczonych. Sukcesywnie dąży się do tego, że opis aplikacji, który kiedyś tworzyło się w UML’u dzisiaj zastępuje dokument lub seria calli z klientem, na podstawie których wiadomo z czego poskładać daną aplikację. Na pewno jest to dość duże uproszczenie i spłycenie tego, co aktualnie robią programiści, natomiast koniec końców ktoś zawsze będzie musiał przetłumaczyć klientowe “ja chcę to” na coś bardziej formalnego i dopytać tego klienta o całą masę szczegółów. Czy sztuczna inteligencja? Myślę, że jeszcze nie prędko