Successfully reported this slideshow.
Your SlideShare is downloading. ×

Microservices on the Edge

Advertisement

More Related Content

Advertisement
Advertisement

Related Books

Free with a 30 day trial from Scribd

See all

Microservices on the Edge

  1. 1. Microservices on the Edge James Higginbotham API Architect @launchany
  2. 2. Introduction
  3. 3. A Little Background…
  4. 4. Fog Computing The collaboration of resources from ‘edge nodes’ for the purposes of computation, storage, analysis and management of devices and data
  5. 5. Edge Computing in 2001 +
  6. 6. What’s Different Now?
  7. 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. 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. 9. Edge computing demonstrates some of the same limitations of the pre-cloud world: No elasticity or flexibility
  10. 10. What if we could bring some elasticity and flexibility of our cloud native architecture to edge computing?
  11. 11. The Proof of Concept
  12. 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. 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. 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. 15. Demo
  16. 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
  17. 17. Thanks Ya’ll James Higginbotham james@launchany.com http://launchany.com @launchany
  18. 18. QUESTIONS

Editor's Notes

  • 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

×