orchestrating cloud-native and traditional application architectures
TRANSCRIPT
Orchestrating Cloud-‐Nativeand Traditional Application Architectures
Sinclair Schuller, [email protected]
A PPRENDA.COM
Let’s Start With Some Facts
A PPRENDA.COM
Existing investments in enterprise IT aren’t going anywhere
FAC T # 1
A PPRENDA.COM
Apps can be cloud native, enterprise IT IS NOT
FAC T # 2
A PPRENDA.COM
Most cloud native apps written in the enterprise WILL HAVE non-‐cloud native
dependencies
FAC T # 3
A PPRENDA.COM
What do we mean when we say “traditional” application architectures?
A PPRENDA.COM
• Apps are monolithic
• Dependencies on “heavy” non-‐volatile tech
• Configuration is embedded and static
• Infrastructure specificityis everywhere
• Lack of decomposed deployability
• Lack of portabilityRDBMS RDBMS Mainframe
Data Tier Adapter
Business Logic Tier
UI Tier
A PPRENDA.COM
A PPRENDA.COM
Decompose all existing enterprise apps into microservices
OP T ION # 1
A PPRENDA.COM
OP T ION # 1
Decompose all existing enterprise apps into microservices
A PPRENDA.COM
Leverage CI/CD tooling and platforms with hybrid architecture capabilities
OP T ION # 2
A PPRENDA.COM
Leverage CI/CD tooling and platforms with hybrid architecture capabilities
OP T ION # 2
A PPRENDA.COM
Let’s Look at this Optionvia an UrbanCode Demo
A PPRENDA.COM
Hybrid Application and Team Structure
APPRENDA D EPLOYMENT
• Back end .NET API service used by multiple applications
• Customer and inventory data in SQL Server• Leverages Apprenda REST APIs
KUBERNETES D E PLOYMENT
• Front end (UI) Flask application
• Services integration
• Leverages Kubernetes API• Connects to Apprenda .NET back end
UrbanCode Application
Apprenda Components Kubernetes Components
DEV TEAM #1 ( .NET) DEV TEAM #2 (PYTHON)
A PPRENDA.COM
App Architecture for the Demo
Google Service
Google Service
eCommerce Frontend
.NET Web API Sales Portal
Databases EnterpriseAdd-‐ons
Additional Upstream and Downstream Enterprise Applications and Services
(via REST)
(via REST)
.py flask
Microsoft .NET
A PPRENDA.COM
What’s Missing?
• Sturdiness – Orchestration is “task driven” and not inherent
• Safe – No policy enforcement (security, runtime expectations)
• Deterministic dependency behavior –Big & slow vs fast and small
• Dynamic runtime change – Lack of ability to react to operating context
• Easy data access – Lack of ability to readily access state data
A PPRENDA.COM
Leverage a platform that understandsthe mechanics of “mixed era” apps
OP T ION # 3
A PPRENDA.COM
OP T ION # 3
Leverage a platform that understandsthe mechanics of “mixed era” apps
A PPRENDA.COM
Kubernetes as Part of aMixed Mode Architecture
A PPRENDA.COM
Why Kubernetes?
TECH10 years of Google R&D in container orchestration
COMMUNITYCannot buy network effect
Largest community
Not built for single vendor
MARKETMost Fortune 500
Wins search volume
Growing vendors
A PPRENDA.COM
Understanding Apprenda
ü Platform for cloud native (via docker) and existing apps
ü Excels at “heavy, non-‐volatile” app servers like JBoss, WebSphere, IIS
ü Strong Windows support (.NET, Windows Services, etc.)
ü Scheduler understands “warm & waiting” servers that receive workloads
A PPRENDA.COM
Allow trivial co-‐habitation and composition of “mixed era” applications
Goal End State
A PPRENDA.COM
Apprenda Scheduler
Policy Context
NodeNV Node (Apprenda Native)
Kubelet
Pod Pod
Proxy
Container Container
Container Manager
“Hot” Managed Server Instance
App 1 Instance
App nInstance De
pendency M
anager
(Bindings &
Runtim
e)
Decomposer K8S SchedulerMapper
Service Catalog & ProxyShared Base Services
Apprenda Archive
INJ ECT IONS INJ ECT IONS
A PPRENDA.COM
Community Participation
• Simplifying post-‐compile extensibility of Kubernetes
• Windows support
• Enterprise readiness
• Integrations with popular enterprise subsystems
Questions?
