Container Camp 2017 - Geographically distributed microservices with containers
•Als PPTX, PDF herunterladen•
2 gefällt mir•194 views
Running applications and services across several cloud providers and/or data centers can bring many benefits for organisations. Actually, in some cases it can even be a mandatory requirement. Making your application stack compliant with multiple cloud providers can be problematic as there are differences between cloud providers, for example in networking configurations. And to make things even more difficult, you should have a way to secure the intra-services’ communications between many cloud providers. In practice this means cumbersome network configurations with VPN and other networking security solutions. Luckily containers and modern (container) overlay networks can solve this complexity for you.
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (8)
Ähnlich wie Container Camp 2017 - Geographically distributed microservices with containers
Ähnlich wie Container Camp 2017 - Geographically distributed microservices with containers (20)
Mehr von Kontena, Inc.
Mehr von Kontena, Inc. (13)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Container Camp 2017 - Geographically distributed microservices with containers
- 1. Building geographically distributed microservices with containers
- 2. About Me Jussi NummelinName Current Work @jnummelin / jnummelinTwitter / Github Software Architect @ Kontena, Inc. Previous Tecnotree, Digia, Tieto, Nokia, … Bio All-around handyman on technical topics. Passionate developer and solution architect Avid fly-fisher
- 4. Yes demo
- 5. Geographical distribution “the natural arrangement and apportionment of the various forms of animals and plants in the different regions and localities of the earth” Merriam-Webster dictionary
- 6. Geographical distribution “the natural arrangement and apportionment of the various software components of systems and services in the different regions and localities of the earth” @JNummelin, 2017
- 7. Multi DC benefits Superior resiliency Hybrid Solutions Regulatory requirements Avoid vendor lock-in
- 8. Multi DC challenges Deployment orchestration Networking Connectivity between DCs/clouds Security
- 9. MultiDC app platform reqs Easy deployment of apps Network level abstraction Secure connectivity between apps
- 10. Options VPNs between clouds DIY deployment orchestration Containers Platform?
- 12. Containers
- 13. Containers FTW Efficient use of resources Application portability Environment parity Easy ´deployability´
- 15. Overlay Network An overlay network is a computer network that is built on top of another network. Nodes in the overlay network can be thought of as being connected by virtual or logical links, each of which corresponds to a path, perhaps through many physical links, in the underlying network. - Wikipedia
- 16. In Practice (with Kontena & Weave)
- 18. Network details Kernel Open V-Switch handles routing Standard VXLAN overlay IPSec with AES GCM encryption
- 19. In practice
- 20. Scheduler Needs to understand locations Apps deployed on many locations Location pinning
- 21. But what about the microservices?
- 22. Conway’s Law: Any organization that designs a system… Murphy’s Law: Anything that can go wrong will go wrong
- 23. Services still care CAP theorem Split brains Network glitches App level issues
- 24. Somewhat simplified Apps don’t care about infra Apps don’t care on network encryption Location abstracted (to a degree)
- 25. Good application principles Circuit breakers Don’t “cache” DNS results Figure out your consistency model
Hinweis der Redaktion
- Why would one want to run apps across clouds / datacenters
- Single cloud region halt does not halt your app Natural disasters Mis config, AWS example Data has to be within EU for example Do not tie yourself into one provider Hybrid solutions Access to in-house private assets Oracle running in the basement
- Configuration management is a pain How do you deploy your app into multiple clouds Networking is different in all providers How to enable connectivity between clouds Securely How will your services find each others between clouds Some services are internal, microservices
- App developers should not have to worry about DC/cloud provider details Apps can connect to other apps “natively”, no need to worry about any network level details Network level security should be taken care of by the “platform”
- Script your way out VPNs for inter-cloud connectivity Anyone setup VPN knows it’s a bit of a pain Not all cloud provider provide private networking Containers help to solve some of the issues Ready made cross-cloud platform, are there any?
- After a few weeks/months system looks like this, a perfectly working system You have every feature that you need, and still some duck tape for the future What if that generator dies? Fun to build these kinds of things, but maybe not best use for your time (and company money)
- Why is everyone talking about containers? You can run multiple apps on one single host with ease Any host with container engine can run any app As long as they are using the standard image format Java reference Deploying an app is basically two step process, pull image and run it
- Containers abstract the provider out Overlay networking as an enabler Abstract provider networking details out Transparent security at low level networking
- Bunch of other alternatives too Kubernetes Docker Swarm Rancher Networking Calico Kuryr Weave Flannel
- Sleeve user space routing User space encryption, if not disabled UDP “custom” tunneling Fastdp Weave configures OVS module in kernel Kernel level routing VXLAN headers used Some NICs offer VXLAN acceleration, packet transformations on hardware Fastdp w/ IPSec ESP protocol used AES w/ GCM for encryption
- (container) scheduler needs to understand your infra locations To some level Scheduler should be able to spread app instances into different “zones” Scheduler should be able to pin services in a certain location Placement-pref spread in Swarm
- Conway’s law is kinda important when thinking about distributed systems But there’s far more important law to think about Murphy’s Law Things When your running multiple instances and at multiple different locations at the same time, likelihood of things breaking gets higher And when things break, they break in more than one place Personal experience: And things usually break during bank holidays. Christmas time, Easter, Mid-summer in Finland
- Even if the network is abstracted, CAP still applies Some one can still use an excavator and cut the fibers So at app level, still use Circuit breakers
- Linkerd, Istio, Hystrix Many apps “cache” DNS results after startup For example Ruby Mongo driver used to do this System level consistency model For strongly consistent systems, geo dist might not even work Chaos engineering Run few alpha CoreOS boxes in prod