neXt NU

Neues Umgebungskonzept

für neXt-Lab Projekte

Die Reise

  1. Ziele
  2. Hindernisse
  3. Rahmenbedingungen
  4. Lösungsideen
  5. Proof of Concepts
  6. Nun backen wir Umgebungen

1. Ziele

1.1 Ziele

  • Provisionierung, Konfiguration & Deployment zusammenfassen
  • Beliebig viele Umgebungen aufbauen und wieder abreißen
  • Kosten zuordbar
  • Wiederverwendung von Code & Ressourcen wo immer möglich

2. Hindernisse

  • Konfigurationen verstreut, redundant und heterogen
  • Etablierte, teilw. komplexe Prozesse treffen auf elastische Rahmenbedingungen & Anforderungen
  • Einzelne Komponenten nur bedingt full-cloud-ready (z.b. Tibco, SAG, FBZE)
  • Aktuelle Cloudformation & Lambda Lösungen zu unflexibel für gewünschte Use-Cases, teilw. nicht mehr zeitgemäß
  • Serverless Technologien (Aurora, Fargate, Lambda) bringen Vorteile aber auch Anforderungen
     
  • Und was ist mit
    Tee bzw. Kibana & Grafana?

3. Rahmenbedingungen

  • Fester Rahmen für elastische Umgebungen
  • Ressourcen auf allen vier Ebenen möglich
  • Serverless Technologien bedeutet Cloud-Computing in Reinkultur. In der AWS gibt's dafür u.a.:
    • Aurora (DB)
    • Fargate (ECS/EKS)
    • Lambda (FaaS)

 

 

Statisch, Elastisch & Serverless

Stages & Umgebungen auf 4 Ebenen

  • 1 Account (tag: n/a)
    • 2a Stage Fachlich/kaufm. (tag: CostReference)
      • 2b Stage Tech. (tag: Stage)
        • 3 Environment - Freie Umgebungen (tag: Environment)
          • 4 Service - Services & Applikationen (tag: ApplicationName)

 

 

 

Account (1)

Stage (2a)

Stage (2b)

Environment (3)

eu
eu-1
eu-x

...

ieu
bbu
ieu-1
ieu-rutk
ieu-x

...

itu
sbu
itu-15
itu-lup
itu-rutk
kamelOne
...

abn
abn-sat

...

prd
demo
schulung
failOver
spiegel
...

PRE

PRD

DEV

TEST

ABN

LIVE

EU

IEU

ITU

ABN

PRD

Service (4)

Pro Stage / Umgebung: fachl. & techn. Services & Applikationen

Stages & Umgebungen auf 4 Ebenen

4. Lösungen

  • Für die größten Painpoints erste Lösungen skizzieren

Konvention vor Konfiguration

  • Vereinfachung ist Kernmotivation
  • Konventionen sind fest, Umgebungen elastisch
  • Konventionen müssen Teamübergreifend
    abgestimmt werden.

 

 

Secrets (Pfade & Struktur)

env/[stage|all]/[environment|all]/[KID|all]/[TypeName]
{
  "engine": "${engine}",
  "username": "${username}",
  "password": "${password}",
  "alias": "konbel-${env}-db.konbel${acc-url}.comp.db.de",
  "host": "${host}",
  "dbname": "${dbname}",
  "port": "3306"
}
env/all/ldap
env/IEU/all/els
env/ITU/kamelOne/all/db/konbelReader
env/IEU/ieu-13/all/amqAdmin
env/ITU/itu-lup/TraSrv/BasicAuth

Kibana Dashboards

fields:
 env: <env>

Text

filebeat.yml:

5. Proof of Concepts

  • Think Big, start Smart.
  • Aus vielen
    Überlegungen
    zwei Enabler (1) / (2)
    ausgesucht.

Enabler 1: SAG as a Docker

  • It's time for a demo

 

 

 

Enabler 2: BiÜ-to-go

  • Provisioning
  • Configuration
  • Deployment
  • BiÜ-Import
     
  • Demo

 

 

 

Enabler 2: BiÜ-to-go

Enabler 2: BiÜ-to-go

6. Nun backen wir Umgebungen

Pipelines
CF-Stacks
Konventionen
Gehirn-Schmalz
JSON-Templates

AMQ
Redis
Secrets
ECS/EC2
OracleDB
Loggroups
PostgressDB
DNS-Einträge
...

Made with Slides.com