Building applications for cloud-native infrastructure that are resilient, scalable, secure, and meet compliance and IT objectives gets complicated. Another wrinkle for the organizations with which we work is the fact they need to run across a hybrid deployment footprint, not just Kubernetes. At Solo.io, we build application networking technology on Envoy Proxy that helps solve difficult multi-deployment, multi-cluster, and even multi-mesh problems.
In this webinar, we’re going to explore different options and patterns for building secure, scalable, resilient applications using technology like Kubernetes and Service Mesh without leaving behind existing IT investments. We’ll see why and when to use multi-cluster topologies, how to build for high availability and team autonomy, and solve for things like service discovery, identity federation, traffic routing, and access control.
How does Solo help do this?
Help pick right tech when it’s warranted (Envoy)
Hedge when market still volatile (SMH)
Simplify adoption
Enterprise focus (security, heterogeneous)
Solve the problem everywhere regardless of technology, infrastructure, footprint
On prem/public cloud/hybrid
Any service mesh technology
VMs, containers, et. al
Kubernetes the defacto way to build and deploy containeriszed microservices … but not everything runs in Kubernetes, and not everything will run on premises
Need a way to automate handling of explosive numbers of workloads (microservices)
Placement of workloads AKA deployments
Autoscale, health check, start/stop, rebalance, scale up/down
Building applications for Kubernetes (or any cloud native platform) is fundamentally different
Why Kubernetes won:
* community
Right level of API
Extensible
Declarative configuration model
Foundation of DevOps and Automation model
Adopting microservices to go fast!
Need a way to automate handling of explosive numbers of workloads (microservices)
Placement of workloads AKA deployments
Autoscale, health check, start/stop, rebalance, scale up/down
Building applications for Kubernetes (or any cloud native platform) is fundamentally different
Why Kubernetes won:
* community
Right level of API
Extensible
Declarative configuration model
Foundation of DevOps and Automation model
Adopting microservices to go fast!
Need a way to automate handling of explosive numbers of workloads (microservices)
Placement of workloads AKA deployments
Autoscale, health check, start/stop, rebalance, scale up/down
Building applications for Kubernetes (or any cloud native platform) is fundamentally different
Why Kubernetes won:
* community
Right level of API
Extensible
Declarative configuration model
Foundation of DevOps and Automation model
Adopting microservices to go fast!
Need a way to automate handling of explosive numbers of workloads (microservices)
Placement of workloads AKA deployments
Autoscale, health check, start/stop, rebalance, scale up/down
Building applications for Kubernetes (or any cloud native platform) is fundamentally different
Why Kubernetes won:
* community
Right level of API
Extensible
Declarative configuration model
Foundation of DevOps and Automation model
Adopting microservices to go fast!
Need a way to automate handling of explosive numbers of workloads (microservices)
Placement of workloads AKA deployments
Autoscale, health check, start/stop, rebalance, scale up/down
Building applications for Kubernetes (or any cloud native platform) is fundamentally different
Why Kubernetes won:
* community
Right level of API
Extensible
Declarative configuration model
Foundation of DevOps and Automation model
Adopting microservices to go fast!
Need a way to automate handling of explosive numbers of workloads (microservices)
Placement of workloads AKA deployments
Autoscale, health check, start/stop, rebalance, scale up/down
Building applications for Kubernetes (or any cloud native platform) is fundamentally different
Why Kubernetes won:
* community
Right level of API
Extensible
Declarative configuration model
Foundation of DevOps and Automation model
Adopting microservices to go fast!