Microservices on the Edge
•Transferir como PPTX, PDF•
3 gostaram•3,504 visualizações
How concepts from cloud native architecture can be used to drive edge computing/fog computing architecture
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (20)
Semelhante a Microservices on the Edge
Semelhante a Microservices on the Edge (20)
Mais de LaunchAny
Mais de LaunchAny (20)
Último
Último (20)
Microservices on the Edge
- 1. Microservices on the Edge James Higginbotham API Architect @launchany
- 2. Introduction
- 4. Fog Computing The collaboration of resources from ‘edge nodes’ for the purposes of computation, storage, analysis and management of devices and data
- 5. Edge Computing in 2001 +
- 7. Cloud Native Architecture Need Solution Servers Cloud Servers are abundant (e.g. EC2) Database Various vendors, can scale up and out (e.g. RDS or self-install) File Storage File and Object storage abundant (e.g. EFS, S3, Ceph) Messaging Message brokers abundant (e.g. SNS/SQS, RabbitMQ) Stack Definition Declarative Infrastructure (e.g. CloudFormation, SaltStack, Terraform, BOSH)
- 8. Edge Computing Architecture Need Solution Servers Hardware must be installed ahead of time Database Limited footprint/storage requires careful selection File Storage File storage limited, can cluster block devices Messaging Message brokers abundant, limited by footprint requirements Stack Definition Infrastructure is hardware
- 9. Edge computing demonstrates some of the same limitations of the pre-cloud world: No elasticity or flexibility
- 10. What if we could bring some elasticity and flexibility of our cloud native architecture to edge computing?
- 11. The Proof of Concept
- 12. Hardware List • Raspberry Pi 2 • 6-port USB Charger • 1’ micro USB cables • 1’ Cat 5 cables + switch • 3’ thin HDMI cables • HDMI Switcher (optional) • Projector (optional, for initial Pi configuration)
- 13. Docker Environment • Hypriot Raspbian distribution • Docker 1.6.0 • OverlayFS • http://blog.hypriot.com/ • Docker Images: • hypriot/rpi-redis • hypriot/rpi-ruby • (Also avail: Node, Go, Python, Java, MySQL, …)
- 14. Architecture RedisMessage Broker Dashboard WX API Solar Panel API Platform Services Application Services Solar Panel Aggregator WX Collector Solar Panel Collector Microservice Boundary
- 15. Demo
- 16. Future Considerations Build trigger logic from events/analysis Shared platform services – Device-specific integration services (logging/ELK) – Network-specific services (MQTT, Internal DNS) Service discovery and orchestration – Docker Swarm, Hashicorp Consul/Atlas Deployment services – Upgrade/rollback using blue-green deployment
- 18. QUESTIONS
Notas do Editor
- Based in Austin, TX. API consulting, including architecture, design, deployment, and training. API 101 for Capital One, book, cloud native architecture
- Colleague’s previous startup 10 years ago – managed solar panel farm, no viable comm solution, built mesh network, deployed Lua services for data collection/aggregation; Spoke about how we would architect it with today’s technologies… As we researched it, we found that a name had been assigned… (Solar Power Technologies Inc now Drake)
- This kind of architecture is what some are calling ‘Fog Computing’, which is defined as the collaboration of resources from ‘edge nodes’ for the purposes of computation, storage, analysis and management of devices and data
- This isn’t a new idea. I was involved with a startup in 2001 with similar ideas. We wanted to combine the compute and storage resources of desktops on the edge of the Internet with peer-to-peer networks and SOAP web services to share and collaborate on data and business processes – rather than centrally-located web services within IT.
- What’s different? The push toward modern, Hypermedia-based Web APIs, Microservice Architectures, and the introduction of Container-based software deployment and distribution. Microservices emerging as architectural pattern. Modularization, technology freedom, easier deployment. DEF: Loosely coupled service-oriented architecture with bounded contexts
- Containers are popular for development and starting to emerge in production environments
- Containers are popular for development and starting to emerge in production environments
- More difficult deploys to bare metal, no declarative or immutable infrastructure
- Specifically, containers, which provide us with the flexibility of virtualization we have from cloud infrastructure that allow us to spin up and down servers
- Microservice spans processes/containers. Each process its own container to allow me upgrade the API without shutting off collectors. THINK ABOUT HOW YOU WANT TO CONTROL/MANAGE YOUR MICROSERVICE LIFECYCLE INCLUDING PROCESSES
- Cat /proc/cpuinfo to show 4 core Pi Show Docker Compose file and discuss each container, shared volumes and links Launch each container Open browser to dashboard and show data, discuss microservice pub/sub design ?Stop collectors, refresh browser?
- Blue/green/Immutable infrastructure on Docker – JEROME’s TALK YESTERDAY ON IMMUTABLE INFRASTRUCTURE, SHARED NETWORK TO TROUBLESHOOT, and FASTER DEPLOYMENT BY BUILDING ONLY WHAT IS NECESSARY