Building geographically distributed microservices with containers
•Download as PPTX, PDF•
0 likes•153 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. In this session, we'll dive deep into how to easily setup a container platform hosted on multiple different cloud providers with a secured overlay networking for intra-service communications. Participants will learn how to utilize containers and overlay networks to build highly resilient microservice architectures.
Recommended
Recommended
More Related Content
Similar to Building geographically distributed microservices with containers
Similar to Building geographically distributed microservices with containers (20)
More from Kontena, Inc.
More from Kontena, Inc. (13)
Recently uploaded
Recently uploaded (20)
Building geographically distributed microservices with containers
- 1. Building geographically distributed microservices with containers
- 3. 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
- 4. 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”
- 5. Distribution Levels Availability Zones < 10ms Regions within a continent < 100ms Global regions > 100ms
- 6. Benefits Superior resiliency Hybrid Solutions Regulatory requirements Avoid vendor lock-in
- 7. Challenges Deployment orchestration Networking Connectivity between DCs/clouds Security
- 8. Requirements Easy deployment of apps Network level abstraction Secure connectivity between apps
- 9. Options VPNs between clouds DIY deployment orchestration Containers Platform?
- 11. Containers FTW Efficient use of resources Application portability Environment parity Easy ´deployability´
- 12. In Practice with
- 14. 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. Network details Kernel Open V-Switch handles routing Standard VXLAN overlay IPSec with AES GCM encryption
- 18. Scheduler Understands zones Spreads deployments Supports location pinning
- 19. But what about the microservices?
- 20. Murphy’s Law Anything that can go wrong will go wrong
- 22. Services still care CAP theorem Split brains Network glitches App level issues
- 23. Abstractions FTW Apps don’t care about infra Apps don’t care on network encryption Location abstracted (to a degree)
- 24. Good application principles Service Mesh Don’t “cache” DNS results Figure out your consistency model
- 25. Summary Containers FTW Overlay networks ease up many things Murphy’s Law Failure testing Distributed systems are still HARD
Editor's Notes
- Why would one want to run apps across clouds / datacenters Focus on platform issues and solutions, not so much app level What I mean with platform?
- Single cloud region halt does not halt your app Natural disasters Mis config, AWS example Locality, latency issues 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
- Bunch of other alternatives too Kubernetes Docker Swarm Rancher Networking Calico Canal Flannel …
- Containers abstract the provider out Overlay networking as an enabler Abstract provider networking details out Transparent security at low level networking
- Each node relays data for the network. All mesh nodes cooperate in the distribution of data in the network DNS helps service discovery Data between apps traverses NATs Overlays can support multicast across clouds Security on network level
- (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 Kube failure domain zones & SelectorSpreadPriority
- 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
- 500-700 containers lost at sea each year Force majoures still happen Numerous examples of connectivity breaks between datacenters Few years ago in Finland main fiber line cut with an excavator half of the country suffered
- 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, Conduit, Aspen Mesh 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